US20090132418A1 - Electronic payment processing system - Google Patents

Electronic payment processing system Download PDF

Info

Publication number
US20090132418A1
US20090132418A1 US12/357,278 US35727809A US2009132418A1 US 20090132418 A1 US20090132418 A1 US 20090132418A1 US 35727809 A US35727809 A US 35727809A US 2009132418 A1 US2009132418 A1 US 2009132418A1
Authority
US
United States
Prior art keywords
merchant
payment
handler
profile
unique
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
US12/357,278
Inventor
Leon N. Morsillo
Terry H. Zeigler
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.)
Datacap Systems Inc
Original Assignee
Morsillo Leon N
Zeigler Terry H
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 Morsillo Leon N, Zeigler Terry H filed Critical Morsillo Leon N
Priority to US12/357,278 priority Critical patent/US20090132418A1/en
Publication of US20090132418A1 publication Critical patent/US20090132418A1/en
Assigned to DATACAP SYSTEMS, INC. reassignment DATACAP SYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MORSILLO, LEON N., MR., ZEIGLER, TERRY H., MR.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Definitions

  • Electronic payments e.g., credit cards, debit cards, gift cards
  • Electronic payments may also be accepted by vending machines, kiosks, automated tellers or other systems where a human is not needed to conduct the transaction or process an electronic payment as tender for the transaction.
  • FIG. 1 illustrates an example architecture used to process electronic payments for merchant transactions.
  • the architecture includes a merchant system 110 , a payment handler 120 , a communication network 130 , and a payment processing system 140 .
  • the merchant system 110 may be a hardware system (e.g., electronic cash register (ECR), point of sale (POS)) or may be a software system (e.g., POS).
  • ECR electronic cash register
  • POS point of sale
  • the merchant system 110 may track items purchased and generate an invoice/sales receipt based on the cost of those items purchased and any taxes and/or discounts applied.
  • the merchant system 110 may include an interface for gathering data about purchased items.
  • the interface may include, but is not limited to, a scanner to scan codes associated with items (e.g., UPC codes), a keyboard to enter data associated with items, or a touch screen to select items.
  • the merchant system 110 may be tied to other systems (e.g., inventory system, management system).
  • the merchant system 110 may also include an interface to gather electronic payment information (e.g., card number).
  • the interface may include, but is not limited to, a card reader (swiper), a scanner, a keyboard, or a touch screen.
  • the payment handler 120 may process the electronic payment information and purchase transaction data (e.g., payment amount) to create electronic payment transactions and communicate the electronic payment transactions to the payment processing system 140 .
  • the payment handler 120 may be separate from the merchant system 110 , interfaced to the merchant system 110 or integrated into the merchant system 110 .
  • the payment handler 120 may receive the payment amount from the merchant system 110 or the payment amount may be entered into payment handler 120 .
  • the payment handler 120 may receive the electronic payment information from the merchant system 110 or an electronic payment information device (not illustrated) connected to the payment handler 120 , or the electronic payment information may be entered into payment handler 120 .
  • the payment handler 120 may include an interface to gather the electronic payment information.
  • the interface may include, but is not limited to, a card reader, a scanner, a keyboard, or a touch screen.
  • the payment handler 120 may be configured to operate with a specific payment processing system 140 (create electronic payment transactions in format required).
  • the payment handler 120 may also be configured for a specific merchant-payment processor relationship (merchant account). The configuration of the payment handler 120 is discussed in more detail later.
  • the communication network 130 provides communications between the payment handler 120 and the payment processing system 140 .
  • the communication network 130 may be a phone network, the Internet and/or a wireless network.
  • the payment processing system 140 receives and processes the electronic payment transactions from the payment handler 120 .
  • the electronic payment transactions received may include information related to the transaction (e.g., payment amount), information related to the electronic payment used (e.g., card number), and information related to the merchant (e.g., merchant identifying information).
  • the payment processing system 140 may determine if the electronic payment transaction received is authorized for the merchant (e.g., does merchant accept that type of credit card) and can be processed (e.g., is transaction amount within card limit of the purchaser). Once the transaction is authorized/approved, the payment processing system 140 may process payment from the card company to the merchant based on identification of the merchant included in the electronic payment transaction.
  • FIGS. 2A-2C illustrate several example merchant system-payment handler architectures.
  • FIG. 2A illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are not interfaced together or communicating directly with one another.
  • the merchant system 110 does not communicate payment amount to the payment handler 120 so the payment amount needs to be entered (manually) into the payment handler 120 .
  • the payment handler 120 may include a user interface (e.g., keyboard) for entering the payment amount. Additionally, cross referencing may be required between the purchases processed in the merchant system 110 and the electronic payment transactions processed in the payment handler 120 .
  • the payment handler 120 may include an electronic payment interface (e.g., card reader, scanner, keyboard) for accepting data related to the consumer and their electronic payment (e.g., credit card number).
  • the payment handler 120 is used as a data terminal to enter payment amount and electronic payment information.
  • FIG. 2B illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are interfaced together and communicate therebetween.
  • the merchant system 110 provides the payment amount to the payment handler 120 .
  • the merchant system 110 may include an electronic payment interface for accepting electronic payment information and may provide the electronic payment information to the payment handler 120 .
  • FIG. 2C illustrates an architecture where the merchant system 110 and the payment handler 120 are integrated into a single device.
  • the payment handler 120 may be software, hardware or firmware within the merchant system 110 .
  • the payment handler 120 may receive the payment amount from the merchant system 110 .
  • the merchant system 110 may include an electronic payment interface for accepting electronic payment information and may provide the electronic payment information to the payment handler 120 .
  • a merchant and a payment processing system 140 execute an agreement for the payment processor to handle electronic payment transactions for the merchant
  • the payment processor creates a merchant account for the merchant that identifies the merchant and defines parameters associated with the merchant agreement.
  • the merchant account may define the types of transactions authorized and include various identifications (e.g., merchant ID, payment processor ID, merchant account ID).
  • the merchant account may be stored in the payment processing system 140 .
  • the payment processing system 140 may utilize the p merchant account to identify incoming electronic payment transactions with the merchant, validate the electronic transactions, and process the electronic payment transactions according to the merchant agreement.
  • the payment processing system 140 may require the incoming electronic payment transactions to be a certain format and contain certain data from the merchant account in order to identify, validate and process the electronic payment transactions.
  • the configuration of the payment handler 120 may include defining the format of electronic payment transactions required by the payment processing system 140 .
  • the payment handler 120 may include software (processor application) that defines the electronic payment transaction format required by the payment processing system 140 that will be processing the electronic payment transactions for the merchant.
  • the payment handler 120 provided to the merchant may have the appropriate processor application loaded for the payment processing system 140 .
  • the payment handler 120 may include a profile that defines parameters regarding the merchant agreement (merchant profile) stored therein.
  • the merchant profile may be similar to the merchant account, and the two may contain at least a portion of the same data.
  • the merchant profile may contain data that is required in the electronic payment transaction format for the associated payment processing center 140 .
  • the payment handler 120 may create the electronic payment transaction based on the processor application, the merchant profile, and the payment amount.
  • the merchant profile may be created by a configuration system 150 .
  • the configuration system 150 may receive data about an established merchant account from the payment processing system 140 and create the merchant profile therefrom.
  • the configuration system 150 may also maintain processor applications used by the payment handlers 120 to create the electronic payment transactions for each of the payment processing systems 140 .
  • the merchant profile may be created to work with a specific processor application.
  • the installation and configuration of the payment handler 120 at a merchant location requires that the appropriate processor application and the merchant profile be loaded therein, which is usually too complicated for the typical merchant. Accordingly, vendors are typically utilized to install and configure the payment handlers 120 for merchants. The vendors may be associated with the payment processing systems 140 or may be independent therefrom. The vendors need to obtain an appropriate payment handler 120 having an appropriate processor application loaded thereon. The vendors need to coordinate with the configuration system 150 in order to ensure the merchant profile is created (can not proceed with installation until the client profile is created by the configuration system 150 ).
  • the vendors may obtain the merchant profile from the configuration system 150 by programming the payment handler 120 to request a merchant profile for the specific merchant agreement (the request may need to include multiple identifications associated therewith, such as, merchant ID and merchant agreement ID).
  • the vendors may alternatively obtain the merchant profile by contacting the configuration system 150 directly (e.g., via phone, fax, email) and requesting a download.
  • the vendors may obtain/load the merchant profile prior to arriving at the merchant location to install the payment handler 120 or may obtain/load the merchant profile at the time of installation from the merchant location.
  • the installation of the payment handler 120 includes connecting to merchant system 110 and the communication network 130 .
  • an electronic payment transaction may be processed to ensure it is processed correctly. Any errors in the processing of the electronic payment transaction require troubleshooting and may require communications between at least some subset of the vendor, the configuration system 150 , the payment processing system 140 , and the merchant.
  • the troubleshooting may determine, for example, that the merchant profile created has errors and require the configuration system 150 to recreate the merchant profile, may determine that the merchant profile was loaded incorrectly or the wrong merchant profile was loaded and require the merchant profile to be reloaded, or may determine that the processor application was loaded incorrectly or the wrong processor application was loaded and require the processor application be made available to the vendor for download.
  • the delivery, installation, configuration and validation of the payment handler 120 is a significant cost factor in deploying a new merchant account.
  • the payment handler 120 may need to be reconfigured.
  • attributes related to the merchant account change e.g., allow additional transactions
  • the payment handler 120 may need to be reconfigured.
  • the payment processing system 140 is modified (e.g., data required or format of electronic payment transaction changes, payment processing system 140 contact information (e.g., IP address) changes) the payment handler 120 may need to be reconfigured.
  • the reconfiguration of the payment handler 120 may require the vendor to return for reconfiguration thereof, the payment handler 120 to be returned for reconfiguration, or replaced with a unit that has been reconfigured.
  • the merchant may be provided with instructions that enables them connect to the configuration server 150 in order to download the merchant profile and/or processor application from the configuration system 150 . Regardless of the form of reconfiguration utilized, it may result in delays and additional costs.
  • the payment handlers are typically not tracked and/or associated with merchants. Accordingly, vendors or other parties that have an account with the configuration system 150 and know how to configure a payment handler 120 can establish communication with the configuration system 150 and have a merchant profile associated with a particular merchant loaded on any payment handler 120 having the appropriate processor software loaded thereon (merchant need not purchase or rent payment handler 120 ). Furthermore, vendors or other parties could establish communication with the configuration system 150 and arrange to have a processor application associated with a merchant account downloaded onto payment handlers not originally associated with that payment processor. The coordination with the configuration system 150 to download merchant profiles and/or processor applications associated with a merchant account enables a payment handler 120 to be reused by the same merchant for different merchant agreements or to be used by different merchants.
  • the reprogramming of the payment handlers 120 creates an aftermarket for the devices that is out of the control of the payment processors or equipment manufactures.
  • the aftermarket reduces the amount of payment handlers 120 required for new merchant accounts and thus reduces the profits the payment processors or equipment manufactures can make by charging for the devices as part of the merchant contract.
  • What is needed is a way to simplify/expedite the creation of the merchant profile, simplify the configuration/reconfiguration of the payment handlers 120 , and control the merchant profiles and processor applications that can be loaded onto payment handlers 120 in order to control use thereof.
  • FIG. 1 illustrates an example architecture used to process electronic payments for merchant transactions, according to one embodiment
  • FIGS. 2A-2C illustrate several example merchant system-payment handler architectures, according to one embodiment
  • FIG. 3 illustrates an example process flow for providing access to the configuration system, according to one embodiment
  • FIG. 4 illustrates an example process flow for establishing a merchant account and processing electronic payment transactions therefore, according to one embodiment
  • FIG. 5 illustrates an example no-load architecture used to process electronic payments for merchant transactions, according to one embodiment
  • FIG. 6 illustrates an example process flow for processing electronic payment transactions using the example architecture of FIG. 5 , according to one embodiment
  • FIGS. 7A-D illustrate several example merchant system-hardware payment handler configurations, according to one embodiment.
  • FIGS. 8A-B illustrate several example software merchant system-software payment handler configurations, according to one embodiment.
  • a configuration system may work with numerous payment processing systems (e.g., 140 ) to develop processor applications and merchant profiles used for enabling payment handlers (e.g., 120 ) to operate therewith (create electronic payment transactions with correct data and in correct format).
  • the configuration system (payment systems configuration server (PSCS)) may develop the processor applications in order to create and format electronic payment transactions as required by the payment processing system in order to process electronic payment transactions.
  • PSCS payment systems configuration server
  • the configuration system may create merchant profile templates that define the necessary parameters regarding the merchant account for the specific payment processing systems.
  • the configuration system may then create the merchant profiles by entering data related to the merchant account into the merchant profile template.
  • the configuration system may provide the payment processing systems, equipment manufactures, dealers, installers, system integrators, financial service sales companies, vendors, merchants, or other parties associated with the execution of a merchant account and the installation and configuration of the payment handler required to process electronic payment transactions (hereinafter referred to as merchant account parties) access to the configuration system.
  • merchant account parties Each of the authorized merchant account parties may be provided with an account in the configuration system.
  • the accounts may provide the merchant account parties access to the configuration system to create merchant profiles and download the merchant profiles for storage on the payment handlers.
  • the merchant account parties may log into the system and access an appropriate merchant profile template that they utilize to create the merchant profile for the merchant based on the merchant account.
  • the login may direct the merchant account party to the appropriate template if the merchant account party (or that particular login) is associated with a single payment processing system. If the merchant account party deals with multiple payment processing systems or deals with multiple different account types (that require different merchant profiles) for a single payment processing system the merchant account party may have to select the appropriate template after logging in.
  • the access to the configuration system enables the merchant account parties to create the merchant profiles remote from the configuration system.
  • the access may be via a web based interface or may be via a direct connection to the configuration system.
  • the merchant account party may be provided with a screen (or screens) that prompts them for the data necessary to create the merchant profile.
  • the configuration system may validate that all necessary data has been entered and is the appropriate format (e.g., merchant identification is correct number of characters). Once the data is validated the merchant profile may be created.
  • the merchant account party may upload a file into the configuration system rather then entering the data.
  • the uploaded file may be a merchant profile (contain same data and be in same format).
  • the uploaded file may be a format that the configuration system can extract data from in order to create the merchant profile.
  • the configuration system may validate the uploaded data.
  • a merchant account party may access (log in to) the configuration system to create the merchant profile as soon as the merchant account is created and the information is available.
  • the merchant profile may be created anywhere the merchant account party has access to the configuration system (e.g., anywhere they have web access).
  • the merchant account party may create the merchant profile prior to installation at the merchant location or while performing the installation.
  • the created merchant profile may be loaded/stored in the payment handler at the time it is created or may be stored at a later time.
  • the payment handler utilized may have the processor application preloaded therein (may take a payment handler associated with the payment processing system).
  • the merchant account party may access the configuration system and have the appropriate processor application downloaded.
  • the processor application may be loaded/stored on the payment handler at any time up through installation at the merchant site.
  • the processor application and the merchant profile may be loaded/stored at the same time.
  • the merchant account party that creates the merchant profile may control access to and/or modification of the merchant profile (ID/password protected) as well access to the processor application.
  • the merchant profile creator may also load the merchant profile/processor application on the payment handler and/or install the payment handler.
  • the merchant profile creator may provide other merchant account parties with access to the configuration system in order to load the merchant profile/processor application on the payment handler.
  • the merchant profile creator may grant access to other parties by providing the ID/password (thus giving full access) or may create guest accounts that may provide a range of access authority.
  • the merchant profile creator may assign control thereof to another merchant account party (e.g., sales may assign to installers).
  • a computing device may be utilized to assist the payment handler contact the configuration system in order to have the merchant profile/processor application downloaded thereto for storage therein.
  • the merchant profile/processor application may be downloaded from the configuration system via the communications medium associated with the payment handler.
  • the configuration system may download the merchant profile/processor application to the computing device (presumably a faster connection and processor resulting in a faster download) and the computing device may load the merchant profile/processor application on the payment handler.
  • FIG. 3 illustrates an example process flow for providing access to the configuration system.
  • the operator of the configuration system establishes a relationship with a payment processing system in which the configuration system agrees to support transactions thereto 300 .
  • the configuration system generates a processor application that is used by a payment handler to generate electronic payment transactions in a format required by the payment processing system 310 .
  • the configuration system then generates a merchant profile template that identifies all the merchant/merchant account specific data that is necessary to process the electronic payment transactions 320 .
  • the merchant profile template and the processor application are linked together.
  • the configuration system identifies parties that may have access to the configuration system in order to create merchant profiles for merchants that enter into merchant agreements with the payment processing system 330 .
  • the parties may include the payment processing systems, equipment manufactures, dealers, installers, system integrators, and financial service sales companies.
  • FIG. 4 illustrates an example process flow for establishing a merchant account and processing electronic payment transactions therefore.
  • a merchant agreement is entered into between a payment processor and a merchant that identifies various electronic payment transaction parameters.
  • the merchant agreement may be entered into by the payment processor or by other entities selling merchant accounts for the payment processor.
  • a merchant account is created in the payment processing system 400 based on the agreement.
  • the merchant account may include various identifications (e.g., account, merchant).
  • a merchant account party may utilize the configuration system to create a merchant profile 410 .
  • the merchant profile created may be downloaded to a payment handler to be utilized by the merchant 420 .
  • the merchant profile may be stored therein for processing of electronic payment transactions.
  • the payment handler may already be associated with the appropriate payment processing system (processor application already loaded therein) or the processor application may also be downloaded to and stored on the payment handler as part of the installation/configuration.
  • the installation/configuration of the payment handler may include validating the operation of the payment handler by processing one or more test electronic payment transactions 430 . If the test transactions are processed/validated 440 Yes, the merchant can process electronic payment transaction 450 . If the test transactions can not be processed/validated 440 No, the merchant account party needs to troubleshoot 460 .
  • the troubleshooting may include modifying the merchant profile created ( 420 ) or restoring/reloading the merchant profile ( 430 ).
  • the payment handlers may be assigned a unique identification (e.g., serial number, device identification (DID)).
  • the unique ID may be programmed in the payment handler as a permanent identification that may not be modified.
  • the unique ID may be programmed into the payment handler by a manufacturer when the payment handler is produced.
  • the unique ID may be programmed into non-volatile, non-programmable memory.
  • the unique ID may be stored in the program.
  • the unique ID may be presented on the payment handler (e.g., with a label affixed thereto, engraved therein) so that the unique ID is known.
  • the unique ID of the payment handler used by a merchant may be linked to the merchant profile for the merchant.
  • the unique ID may be linked to the merchant profile by a merchant account party.
  • the unique ID may be associated with the merchant profile when the merchant profile is created or after the profile is created.
  • the unique ID may be associated with the merchant profile prior to installation at the merchant location or during installation. The association of the unique ID to the merchant profile may be required to activate the merchant account.
  • the unique ID may be utilized by the configuration system to manage and control the use of the payment handlers. For example, the configuration system may track whether the payment handler was purchased and/or rented by the merchant, what processor application is associated with the payment handler and whether the processor application has been purchased and/or rented, and whether there is a service contract on the payment handler. Tying the various parameters to unique ID enables the configuration system to control what level of access should be provided to what payment handlers. The configuration system may turn processor application access on or off, or charge for processor applications, depending on the status associate with the unique ID.
  • a merchant account party may access the configuration system and provide the unique ID.
  • the configuration system may look up the status of the unique ID and after validating the status of the unique ID may download a processor application and possibly the merchant profile associated therewith.
  • the access to the configuration system may be via the computing device. The download may be directly to the payment handler.
  • the configuration system may determine that the unique ID is not associated with that processor application and disallow the load, or allow for it with payment for the new processor application. If a merchant account party attempts to reload the processor application and/or merchant profile for a rented payment handler and/or rented processor application and the rent has not been paid the configuration system may preclude the load until the rent is paid.
  • the payment handler may send the configuration system a request for a down load of the merchant profile where the request includes the unique ID.
  • the configuration system validates the unique ID and determines the merchant profile associated therewith and downloads the merchant profile to the payment handler.
  • the configuration system may automatically download the appropriate processor application with the merchant profile.
  • the merchant account party may access the configuration system and request that the payment handler be reconfigured (e.g., have merchant profile and/or processor application reloaded).
  • a merchant account party may access the configuration system and create the new merchant profile and have the new profile downloaded to the payment handler (the associated processor application may also be downloaded).
  • a merchant account party may access the configuration system and change the unique ID associated with the merchant account and then download the appropriate data to the new payment handler.
  • the new payment handler preconfigured can be delivered to the merchant for installation.
  • the unique ID of the old payment handler may remain associated with the merchant in an inactive state until the merchant returns the payment handler. If the merchant doesn't return the unit they may be charged accordingly. Once the payment handler is returned it may be disassociated with the merchant. If the returned payment handler is repaired the unique ID may be reprogrammed and the unit may be made available for a new merchant. The unique ID is reprogrammed rather releasing the existing unique ID in order to avoid inadvertent processing of transactions for the new merchant to the old merchant.
  • a merchant account may provide limited reloads and/or reconfigures unless a service agreement is purchased.
  • the configuration system may determine if a service agreement is in place for the unique ID. If a service agreement is in place the configuration system may allow reloading/reconfiguring. If a service agreement is not in place and the number of reloads/reconfigurations has been exceeded the configuration system may not allow the reload/reconfiguration, may charge for the reload/reconfiguration or may provide the option to purchase a service agreement.
  • the use of the unique ID makes access to the appropriate account easier and also provides the configuration system with additional management and control over the payment handlers and the merchant accounts.
  • a processing switch (multi merchant processing server (MMPS)) is utilized to receive electronic payment transactions that are only identified by the unique ID, look up the merchant profile and processing application associated with the unique ID, and reconfigure the electronic payment transactions to include the associated merchant profile prior to forwarding the electronic payment transactions to the payment processing system.
  • the payment handlers need not have the merchant profile loaded therein.
  • the payment handlers may contain the same processor application regardless of what payment processing system is processing the electronic payment transactions.
  • the processor application may create and format the electronic payment messages in a format that may be processed by the processing switch.
  • the processing switch may have various processor applications stored therein that define the different formats necessary for creating electronic payment transactions for the payment processing systems that it supports.
  • FIG. 5 illustrates an example architecture used to process electronic payments for merchant transactions.
  • the architecture includes the merchant system 510 , the payment handler 520 having a unique ID, the communication network 530 , the processing switch (MMPS) 540 , and the payment processing system 550 .
  • MMPS processing switch
  • the payment handler 520 may receive transaction data (payment amount) and electronic payment information and process the information to create an electronic payment transaction.
  • the payment handler 520 may add the unique ID in the electronic payment transactions.
  • the unique ID may be embedded into the electronic payment transaction or may be included in header data for the electronic payment transaction message.
  • the payment handler 520 does not require programming/configuration of the merchant profile and does need not to have memory for storing the merchant profile.
  • the processing switch 540 may store client side merchant profiles for various merchant accounts (and associated merchants) and may associate the unique ID of the payment handler 520 used by the merchant with the merchant (and their client side merchant profile). The processing switch 540 may receive the electronic payment transactions from the payment handlers 520 having the unique ID included and may look up the unique ID and retrieve the associated merchant profile and associated processor software. The processing switch 540 may then reformat the electronic payment transaction in accordance associated processor software and the merchant profile and forward the reformatted electronic payment transaction to the payment processing system 550 .
  • the use of a unique ID for the payment handler 520 , and the correlation of the unique ID to the merchant profile in the processing switch 540 enables the configuration required to process electronic payment transactions for a merchant to be moved upstream from the payment handler 520 to the processing switch 540 .
  • the formatting of the electronic payment transactions, and inclusion of the merchant profile therein, required by the payment processing system 550 is performed by the processing switch 540 instead of the payment handler 520 .
  • the processing switch 540 may provide merchant account parties access thereto to create merchant profiles, to associate the merchant profiles to the unique ID for the associated payment handler 520 , and to configure the payment handlers (e.g., download processor application that formats electronic payment transactions for the processing switch).
  • the processing switch 540 may be utilized to manage and control the use of the payment handlers 520 as described above with respect to the configuration system 150 .
  • FIG. 6 illustrates an example process flow for processing electronic payment transactions using the example architecture of FIG. 5 .
  • the merchant system processes a transaction for a customer 600 .
  • Electronic payment information e.g., credit card number
  • the transaction information (payment amount) and the electronic payment information are provided to the payment handler where the information is processed and the unique ID associated therewith is added to create an electronic payment transaction and the electronic payment transaction is forwarded to the processing switch 620 .
  • the payment handler may be configured to communicate with the processing switch.
  • the processing switch extracts the unique ID and looks up the merchant profile associated therewith 630 .
  • the processing switch then reformats the electronic payment transaction in accordance with the merchant profile 640 .
  • the reconfiguration includes removing the unique ID and adding the data that the payment processing system requires in order to validate and process the electronic payment.
  • the reformatted electronic payment transaction is provided to the payment processing system where the electronic transactions are processed 650 .
  • the payment handlers described above with respect to FIGS. 1-6 may be provided in various different configurations. The configurations may be based on the type of merchant system and communication network being utilized.
  • the payment handlers may have a unique ID associated therewith.
  • the payment handlers may include memory and have the merchant profile and processor application stored therein if the electronic payment transactions are formatted for and provided to the payment processing system.
  • FIGS. 7A-D illustrate several example merchant system-hardware payment handler configurations.
  • FIG. 7A illustrates an example configuration where the communications network 730 utilized is the public switched telephone network (PSTN).
  • the payment handler 720 (DialTran) may include a processor to process the transactions and a telephone modem (communication device) and a telephone jack (output interface) to transmit the transactions over the PSTN 730 .
  • the processor, the modem, and the jack are not illustrated.
  • a telephone cable may be used to connect the DialTran payment handler 720 to the PSTN 730 .
  • the telephone modem may be separate from the DialTran 720 and connected thereto.
  • the DialTran 720 may be configured to work with a select number of modems and the system will only be guaranteed to work (avoid configuration problems) with one of the select modems.
  • FIG. 7B illustrates an example configuration where the communications network 730 utilized is the Internet.
  • the payment handler 720 may include a processor (not separately illustrated) to process the transactions and break the data into packets for transmission over the Internet 730 .
  • the IPTran payment handler 720 may be physically connected to a DSL data modem and/or router (DSL/Cable router/modem) 722 via an Ethernet cable or may have a wireless connection therebetween.
  • the DSL/Cable router/modem 722 may provide connectivity to the Internet 730 via telephone or coaxial cable. As there are a plurality of different modems/routers 722 that utilize different operational parameters configuration problems may occur.
  • the IPTran 720 may be configured to work with a select number of modems/routers for each type of Internet connection (e.g., DSL, cable) and the system will only be guaranteed to work (avoid configuration problems) with one of the select modems/routers.
  • the DSL/cable router/modem 722 may be included within the IPTran 720 .
  • a DSL IPTran may include a DSL modem/router and a cable IPTran may include a cable modem router.
  • FIG. 7C illustrates an example configuration where the communications network 730 utilized is the Internet.
  • a wireless communication device 724 e.g., wireless network card
  • Using a wireless network may be beneficial for mobile merchant systems or systems located where it may be difficult or costly to run wired telephone or Internet lines.
  • the IPTran 720 may be configured to work with a select number of wireless communication devices and the system will only be guaranteed to work (avoid configuration problems) with one of the select ones.
  • the wireless communication device 724 may be within the IPTran 720 .
  • the merchant may desire to utilize more than one communication network for processing electronic payments (e.g., redundant networks for fallback processing).
  • the merchant may utilize the Internet as their primary communications network and the PSTN as their redundant network if Internet connection is lost.
  • the merchant may desire to connect to the communications network in more than one fashion (e.g., wired and wireless). For example, if the merchant moves the merchant system to a remote location they may switch from connecting to the Internet via a DSL/cable modem/router to a wireless connection.
  • the merchant could utilize multiple payment handlers to enable communications over multiple communication networks (e.g., PSTN, Internet) or to provide multiple connections (e.g., wired, wireless) to the communications network.
  • the merchant may have an IPTran for Internet communications and DialTran for PSTN communications.
  • the payment handler may be capable of utilizing more than one communication network or more than one connection to process electronic payment transactions.
  • the payment handler may automatically switch from communicating over the primary communication network to the secondary network if there is a problem/failure with the primary network.
  • the payment handler may also permit the merchant to selectively switch between which communication network is utilized or between how the connection to the communication network is established.
  • FIG. 7D illustrates an example configuration where the primary communications network 730 utilized is the Internet with the PSTN as the fallback.
  • the payment handler 720 may be a combination of a dial link modem and an IPTran with functionality for automatically switching upon an error in the IPTran or the Internet connection or to allow manual switchover (TwinTran).
  • FIGS. 8A-B illustrate several example software merchant system-software payment handler configurations.
  • FIG. 8A illustrates an example configuration where the software merchant system 810 (e.g., point of sale (POS) application) and the software payment handler 820 (epay) are running and interfaced together on the same device (e.g., computer) 812 .
  • the unique ID used to identify the ePay 820 may be a serial number associated with the ePay 820 or may be a MAC ID associated with the device 812 the software is running on.
  • the merchant system 810 and the ePay 820 are not limited to running on the same device. Rather, the merchant system 810 and the ePay 820 could be run on separate devices capable of communicating with one another without departing from the current scope. In fact, several merchant systems 810 could be networked to a single ePay 820 .
  • the ePay 820 may configure the data for processing by the processor switch 840 .
  • the device 812 may be connected to a communication device (e.g., modem, DSL/Cable router/modem, wireless network card) 826 for providing connectivity to the communication network 830 (e.g., PSTN, Internet).
  • the device 812 may be wired to the communication device 826 (e.g., via an Ethernet cable) or may have a wireless connection therebetween. Alternatively, the communication device 826 may be included within the device 812 .
  • the software merchant system can have redundant paths to communicate with the processor switch 840 .
  • redundant communication paths can exist between the ePay 820 and the payment processing center 850 .
  • FIG. 8B illustrates an example configuration having a modem 328 to communicate with the PSTN 830 , and a DSL/Cable router/modem 822 and a wireless network card 824 to communicate with the Internet 830 .
  • the merchant system 810 and the ePay 820 may be loaded on the same device or different devices.
  • the modem 828 , the DSL/Cable router/modem 822 and/or the wireless network card 824 may be contained within the device having the ePay 820 loaded thereon or on separate devices or may be standalone devices.
  • An embodiment may be implemented by hardware, software, firmware, microcode, or any combination thereof.
  • the elements of an embodiment are the program code or code segments to perform the necessary tasks.
  • the code may be the actual code that carries out the operations, or code that emulates or simulates the operations.
  • a code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements.
  • a code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
  • the program or code segments may be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium.
  • the “processor readable or accessible medium” or “machine readable or accessible medium” may include any medium that can store, transmit, or transfer information. Examples of the processor/machine readable/accessible medium include an electronic circuit, a semiconductor memory device, a read only memory (ROM), a flash memory, an erasable ROM (EROM), a floppy diskette, a compact disk (CD-ROM), an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc.
  • the computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.
  • the code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
  • the machine accessible medium may be embodied in an article of manufacture.
  • the machine accessible medium may include data that, when accessed by a machine, cause the machine to perform the operations described in the following.
  • the term “data” here refers to any type of information that is encoded for machine-readable purposes. Therefore, it may include program, code, data, file, etc.
  • All or part of an embodiment may be implemented by software.
  • the software may have several modules coupled to one another.
  • a software module is coupled to another module to receive variables, parameters, arguments, pointers, etc. and/or to generate or pass results, updated variables, pointers, etc.
  • a software module may also be a software driver or interface to interact with the operating system running on the platform.
  • a software module may also be a hardware driver to configure, set up, initialize, send and receive data to and from a hardware device.
  • An embodiment may be described as a process which is usually depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged.
  • a process is terminated when its operations are completed.
  • a process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.

Abstract

In general, in one aspect, parties associated with a merchant profile may be provided access to a system utilized to create merchant profiles. The system may accept data related to a merchant account from the parties and may validate the data. If any required information is missing or invalid the system may notify the parties. Once all the data is received and validated the system processes the data to create the merchant profile. The merchant profile may be stored in the system for the merchant. The merchant profile may be associated with a unique ID associated with a payment handler utilized by the merchant. The merchant or associated parties may utilize the unique ID to configure the payment handler including downloading processor software. The system may utilize the unique ID to manage and control use of the payment handlers and the processor applications.

Description

    PRIORITY
  • This application is a divisional of, and claims the benefit under 35 USC §120 of, application Ser. No. 11/959,926 entitled “Electronic Payment Processing System” filed on Dec. 19, 2007 and having Leon N. Morsillo and Terry H. Zeigler as inventors. Application Ser. No. 11/959,926 claimed the priority under 35 USC § 119 of Provisional Application 60/870,642 entitled “Method to deploy hardware and software payment systems” filed on Dec. 19, 2006 and having Leon N. Morsillo and Terry H. Zeigler as inventors. Application Ser. Nos. 11/959,926 and 60/870,642 are herein incorporated by reference in their entirety but are not prior art.
  • BACKGROUND
  • Today most merchants, whether brick and mortar or Internet, accept electronic payments (e.g., credit cards, debit cards, gift cards) as tender for transactions. Electronic payments may also be accepted by vending machines, kiosks, automated tellers or other systems where a human is not needed to conduct the transaction or process an electronic payment as tender for the transaction.
  • FIG. 1 illustrates an example architecture used to process electronic payments for merchant transactions. The architecture includes a merchant system 110, a payment handler 120, a communication network 130, and a payment processing system 140. The merchant system 110 may be a hardware system (e.g., electronic cash register (ECR), point of sale (POS)) or may be a software system (e.g., POS). The merchant system 110 may track items purchased and generate an invoice/sales receipt based on the cost of those items purchased and any taxes and/or discounts applied. The merchant system 110 may include an interface for gathering data about purchased items. The interface may include, but is not limited to, a scanner to scan codes associated with items (e.g., UPC codes), a keyboard to enter data associated with items, or a touch screen to select items. The merchant system 110 may be tied to other systems (e.g., inventory system, management system). The merchant system 110 may also include an interface to gather electronic payment information (e.g., card number). The interface may include, but is not limited to, a card reader (swiper), a scanner, a keyboard, or a touch screen.
  • The payment handler 120 may process the electronic payment information and purchase transaction data (e.g., payment amount) to create electronic payment transactions and communicate the electronic payment transactions to the payment processing system 140. The payment handler 120 may be separate from the merchant system 110, interfaced to the merchant system 110 or integrated into the merchant system 110. The payment handler 120 may receive the payment amount from the merchant system 110 or the payment amount may be entered into payment handler 120. The payment handler 120 may receive the electronic payment information from the merchant system 110 or an electronic payment information device (not illustrated) connected to the payment handler 120, or the electronic payment information may be entered into payment handler 120. The payment handler 120 may include an interface to gather the electronic payment information. The interface may include, but is not limited to, a card reader, a scanner, a keyboard, or a touch screen.
  • The payment handler 120 may be configured to operate with a specific payment processing system 140 (create electronic payment transactions in format required). The payment handler 120 may also be configured for a specific merchant-payment processor relationship (merchant account). The configuration of the payment handler 120 is discussed in more detail later.
  • The communication network 130 provides communications between the payment handler 120 and the payment processing system 140. The communication network 130 may be a phone network, the Internet and/or a wireless network.
  • The payment processing system 140 receives and processes the electronic payment transactions from the payment handler 120. The electronic payment transactions received may include information related to the transaction (e.g., payment amount), information related to the electronic payment used (e.g., card number), and information related to the merchant (e.g., merchant identifying information). The payment processing system 140 may determine if the electronic payment transaction received is authorized for the merchant (e.g., does merchant accept that type of credit card) and can be processed (e.g., is transaction amount within card limit of the purchaser). Once the transaction is authorized/approved, the payment processing system 140 may process payment from the card company to the merchant based on identification of the merchant included in the electronic payment transaction.
  • FIGS. 2A-2C illustrate several example merchant system-payment handler architectures. FIG. 2A illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are not interfaced together or communicating directly with one another. The merchant system 110 does not communicate payment amount to the payment handler 120 so the payment amount needs to be entered (manually) into the payment handler 120. The payment handler 120 may include a user interface (e.g., keyboard) for entering the payment amount. Additionally, cross referencing may be required between the purchases processed in the merchant system 110 and the electronic payment transactions processed in the payment handler 120. The payment handler 120 may include an electronic payment interface (e.g., card reader, scanner, keyboard) for accepting data related to the consumer and their electronic payment (e.g., credit card number). The payment handler 120 is used as a data terminal to enter payment amount and electronic payment information.
  • FIG. 2B illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are interfaced together and communicate therebetween. The merchant system 110 provides the payment amount to the payment handler 120. The merchant system 110 may include an electronic payment interface for accepting electronic payment information and may provide the electronic payment information to the payment handler 120.
  • FIG. 2C illustrates an architecture where the merchant system 110 and the payment handler 120 are integrated into a single device. The payment handler 120 may be software, hardware or firmware within the merchant system 110. The payment handler 120 may receive the payment amount from the merchant system 110. The merchant system 110 may include an electronic payment interface for accepting electronic payment information and may provide the electronic payment information to the payment handler 120.
  • When a merchant and a payment processing system 140 (payment processor) execute an agreement for the payment processor to handle electronic payment transactions for the merchant the payment processor creates a merchant account for the merchant that identifies the merchant and defines parameters associated with the merchant agreement. The merchant account may define the types of transactions authorized and include various identifications (e.g., merchant ID, payment processor ID, merchant account ID). The merchant account may be stored in the payment processing system 140. The payment processing system 140 may utilize the p merchant account to identify incoming electronic payment transactions with the merchant, validate the electronic transactions, and process the electronic payment transactions according to the merchant agreement. The payment processing system 140 may require the incoming electronic payment transactions to be a certain format and contain certain data from the merchant account in order to identify, validate and process the electronic payment transactions.
  • Regardless of the type of payment handler 120 used, in order for the electronic payment transactions to be processed the payment handler 120 needs to be configured in order to communicate with the payment processing system 140. The configuration of the payment handler 120 may include defining the format of electronic payment transactions required by the payment processing system 140. The payment handler 120 may include software (processor application) that defines the electronic payment transaction format required by the payment processing system 140 that will be processing the electronic payment transactions for the merchant. The payment handler 120 provided to the merchant may have the appropriate processor application loaded for the payment processing system 140.
  • In addition, the payment handler 120 may include a profile that defines parameters regarding the merchant agreement (merchant profile) stored therein. The merchant profile may be similar to the merchant account, and the two may contain at least a portion of the same data. The merchant profile may contain data that is required in the electronic payment transaction format for the associated payment processing center 140. The payment handler 120 may create the electronic payment transaction based on the processor application, the merchant profile, and the payment amount.
  • Referring back to FIG. 1, the merchant profile may be created by a configuration system 150. The configuration system 150 may receive data about an established merchant account from the payment processing system 140 and create the merchant profile therefrom. The configuration system 150 may also maintain processor applications used by the payment handlers 120 to create the electronic payment transactions for each of the payment processing systems 140. The merchant profile may be created to work with a specific processor application.
  • The installation and configuration of the payment handler 120 at a merchant location requires that the appropriate processor application and the merchant profile be loaded therein, which is usually too complicated for the typical merchant. Accordingly, vendors are typically utilized to install and configure the payment handlers 120 for merchants. The vendors may be associated with the payment processing systems 140 or may be independent therefrom. The vendors need to obtain an appropriate payment handler 120 having an appropriate processor application loaded thereon. The vendors need to coordinate with the configuration system 150 in order to ensure the merchant profile is created (can not proceed with installation until the client profile is created by the configuration system 150).
  • The vendors may obtain the merchant profile from the configuration system 150 by programming the payment handler 120 to request a merchant profile for the specific merchant agreement (the request may need to include multiple identifications associated therewith, such as, merchant ID and merchant agreement ID). The vendors may alternatively obtain the merchant profile by contacting the configuration system 150 directly (e.g., via phone, fax, email) and requesting a download. The vendors may obtain/load the merchant profile prior to arriving at the merchant location to install the payment handler 120 or may obtain/load the merchant profile at the time of installation from the merchant location. The installation of the payment handler 120 includes connecting to merchant system 110 and the communication network 130.
  • Once the payment handler 120 is installed and configured, an electronic payment transaction may be processed to ensure it is processed correctly. Any errors in the processing of the electronic payment transaction require troubleshooting and may require communications between at least some subset of the vendor, the configuration system 150, the payment processing system 140, and the merchant. The troubleshooting may determine, for example, that the merchant profile created has errors and require the configuration system 150 to recreate the merchant profile, may determine that the merchant profile was loaded incorrectly or the wrong merchant profile was loaded and require the merchant profile to be reloaded, or may determine that the processor application was loaded incorrectly or the wrong processor application was loaded and require the processor application be made available to the vendor for download. The delivery, installation, configuration and validation of the payment handler 120 is a significant cost factor in deploying a new merchant account.
  • Furthermore, if the merchant profile or the processor application becomes corrupt the payment handler 120 may need to be reconfigured. Additionally, if attributes related to the merchant account change (e.g., allow additional transactions) the payment handler 120 may need to be reconfigured. Moreover, if the payment processing system 140 is modified (e.g., data required or format of electronic payment transaction changes, payment processing system 140 contact information (e.g., IP address) changes) the payment handler 120 may need to be reconfigured. The reconfiguration of the payment handler 120 may require the vendor to return for reconfiguration thereof, the payment handler 120 to be returned for reconfiguration, or replaced with a unit that has been reconfigured. Alternatively, the merchant may be provided with instructions that enables them connect to the configuration server 150 in order to download the merchant profile and/or processor application from the configuration system 150. Regardless of the form of reconfiguration utilized, it may result in delays and additional costs.
  • The payment handlers are typically not tracked and/or associated with merchants. Accordingly, vendors or other parties that have an account with the configuration system 150 and know how to configure a payment handler 120 can establish communication with the configuration system 150 and have a merchant profile associated with a particular merchant loaded on any payment handler 120 having the appropriate processor software loaded thereon (merchant need not purchase or rent payment handler 120). Furthermore, vendors or other parties could establish communication with the configuration system 150 and arrange to have a processor application associated with a merchant account downloaded onto payment handlers not originally associated with that payment processor. The coordination with the configuration system 150 to download merchant profiles and/or processor applications associated with a merchant account enables a payment handler 120 to be reused by the same merchant for different merchant agreements or to be used by different merchants. The reprogramming of the payment handlers 120 creates an aftermarket for the devices that is out of the control of the payment processors or equipment manufactures. The aftermarket reduces the amount of payment handlers 120 required for new merchant accounts and thus reduces the profits the payment processors or equipment manufactures can make by charging for the devices as part of the merchant contract.
  • What is needed is a way to simplify/expedite the creation of the merchant profile, simplify the configuration/reconfiguration of the payment handlers 120, and control the merchant profiles and processor applications that can be loaded onto payment handlers 120 in order to control use thereof.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The features and advantages of the various embodiments will become apparent from the following detailed description in which:
  • FIG. 1 illustrates an example architecture used to process electronic payments for merchant transactions, according to one embodiment;
  • FIGS. 2A-2C illustrate several example merchant system-payment handler architectures, according to one embodiment;
  • FIG. 3 illustrates an example process flow for providing access to the configuration system, according to one embodiment;
  • FIG. 4 illustrates an example process flow for establishing a merchant account and processing electronic payment transactions therefore, according to one embodiment;
  • FIG. 5 illustrates an example no-load architecture used to process electronic payments for merchant transactions, according to one embodiment;
  • FIG. 6 illustrates an example process flow for processing electronic payment transactions using the example architecture of FIG. 5, according to one embodiment;
  • FIGS. 7A-D illustrate several example merchant system-hardware payment handler configurations, according to one embodiment; and
  • FIGS. 8A-B illustrate several example software merchant system-software payment handler configurations, according to one embodiment.
  • DETAILED DESCRIPTION
  • A configuration system (e.g., 150) may work with numerous payment processing systems (e.g., 140) to develop processor applications and merchant profiles used for enabling payment handlers (e.g., 120) to operate therewith (create electronic payment transactions with correct data and in correct format). The configuration system (payment systems configuration server (PSCS)) may develop the processor applications in order to create and format electronic payment transactions as required by the payment processing system in order to process electronic payment transactions. The configuration system may create merchant profile templates that define the necessary parameters regarding the merchant account for the specific payment processing systems. The configuration system may then create the merchant profiles by entering data related to the merchant account into the merchant profile template.
  • In order to expedite the development and loading of the merchant profiles the configuration system may provide the payment processing systems, equipment manufactures, dealers, installers, system integrators, financial service sales companies, vendors, merchants, or other parties associated with the execution of a merchant account and the installation and configuration of the payment handler required to process electronic payment transactions (hereinafter referred to as merchant account parties) access to the configuration system. Each of the authorized merchant account parties may be provided with an account in the configuration system. The accounts may provide the merchant account parties access to the configuration system to create merchant profiles and download the merchant profiles for storage on the payment handlers.
  • The merchant account parties may log into the system and access an appropriate merchant profile template that they utilize to create the merchant profile for the merchant based on the merchant account. The login may direct the merchant account party to the appropriate template if the merchant account party (or that particular login) is associated with a single payment processing system. If the merchant account party deals with multiple payment processing systems or deals with multiple different account types (that require different merchant profiles) for a single payment processing system the merchant account party may have to select the appropriate template after logging in.
  • The access to the configuration system enables the merchant account parties to create the merchant profiles remote from the configuration system. The access may be via a web based interface or may be via a direct connection to the configuration system. The merchant account party may be provided with a screen (or screens) that prompts them for the data necessary to create the merchant profile. After the merchant account party has entered the data, the configuration system may validate that all necessary data has been entered and is the appropriate format (e.g., merchant identification is correct number of characters). Once the data is validated the merchant profile may be created.
  • In an alternative embodiment, the merchant account party may upload a file into the configuration system rather then entering the data. The uploaded file may be a merchant profile (contain same data and be in same format). Alternatively, the uploaded file may be a format that the configuration system can extract data from in order to create the merchant profile. The configuration system may validate the uploaded data.
  • When a merchant account is established in the payment processing system, a merchant account party may access (log in to) the configuration system to create the merchant profile as soon as the merchant account is created and the information is available. The merchant profile may be created anywhere the merchant account party has access to the configuration system (e.g., anywhere they have web access). The merchant account party may create the merchant profile prior to installation at the merchant location or while performing the installation. The created merchant profile may be loaded/stored in the payment handler at the time it is created or may be stored at a later time.
  • The payment handler utilized may have the processor application preloaded therein (may take a payment handler associated with the payment processing system). Alternatively, the merchant account party may access the configuration system and have the appropriate processor application downloaded. The processor application may be loaded/stored on the payment handler at any time up through installation at the merchant site. The processor application and the merchant profile may be loaded/stored at the same time.
  • The merchant account party that creates the merchant profile (merchant profile creator) may control access to and/or modification of the merchant profile (ID/password protected) as well access to the processor application. The merchant profile creator may also load the merchant profile/processor application on the payment handler and/or install the payment handler. Alternatively, the merchant profile creator may provide other merchant account parties with access to the configuration system in order to load the merchant profile/processor application on the payment handler. The merchant profile creator may grant access to other parties by providing the ID/password (thus giving full access) or may create guest accounts that may provide a range of access authority. The merchant profile creator may assign control thereof to another merchant account party (e.g., sales may assign to installers).
  • A computing device (e.g., laptop computer) may be utilized to assist the payment handler contact the configuration system in order to have the merchant profile/processor application downloaded thereto for storage therein. The merchant profile/processor application may be downloaded from the configuration system via the communications medium associated with the payment handler. Alternatively, the configuration system may download the merchant profile/processor application to the computing device (presumably a faster connection and processor resulting in a faster download) and the computing device may load the merchant profile/processor application on the payment handler.
  • FIG. 3 illustrates an example process flow for providing access to the configuration system. Initially, the operator of the configuration system establishes a relationship with a payment processing system in which the configuration system agrees to support transactions thereto 300. The configuration system generates a processor application that is used by a payment handler to generate electronic payment transactions in a format required by the payment processing system 310. The configuration system then generates a merchant profile template that identifies all the merchant/merchant account specific data that is necessary to process the electronic payment transactions 320. The merchant profile template and the processor application are linked together. The configuration system identifies parties that may have access to the configuration system in order to create merchant profiles for merchants that enter into merchant agreements with the payment processing system 330. The parties may include the payment processing systems, equipment manufactures, dealers, installers, system integrators, and financial service sales companies.
  • FIG. 4 illustrates an example process flow for establishing a merchant account and processing electronic payment transactions therefore. Initially, a merchant agreement is entered into between a payment processor and a merchant that identifies various electronic payment transaction parameters. The merchant agreement may be entered into by the payment processor or by other entities selling merchant accounts for the payment processor. A merchant account is created in the payment processing system 400 based on the agreement. The merchant account may include various identifications (e.g., account, merchant). Once the merchant account is established a merchant account party may utilize the configuration system to create a merchant profile 410.
  • The merchant profile created may be downloaded to a payment handler to be utilized by the merchant 420. The merchant profile may be stored therein for processing of electronic payment transactions. The payment handler may already be associated with the appropriate payment processing system (processor application already loaded therein) or the processor application may also be downloaded to and stored on the payment handler as part of the installation/configuration.
  • The installation/configuration of the payment handler may include validating the operation of the payment handler by processing one or more test electronic payment transactions 430. If the test transactions are processed/validated 440 Yes, the merchant can process electronic payment transaction 450. If the test transactions can not be processed/validated 440 No, the merchant account party needs to troubleshoot 460. The troubleshooting may include modifying the merchant profile created (420) or restoring/reloading the merchant profile (430).
  • The payment handlers may be assigned a unique identification (e.g., serial number, device identification (DID)). The unique ID may be programmed in the payment handler as a permanent identification that may not be modified. The unique ID may be programmed into the payment handler by a manufacturer when the payment handler is produced. For a hardware payment handler the unique ID may be programmed into non-volatile, non-programmable memory. For a software payment handler the unique ID may be stored in the program. The unique ID may be presented on the payment handler (e.g., with a label affixed thereto, engraved therein) so that the unique ID is known.
  • The unique ID of the payment handler used by a merchant may be linked to the merchant profile for the merchant. The unique ID may be linked to the merchant profile by a merchant account party. The unique ID may be associated with the merchant profile when the merchant profile is created or after the profile is created. The unique ID may be associated with the merchant profile prior to installation at the merchant location or during installation. The association of the unique ID to the merchant profile may be required to activate the merchant account.
  • The unique ID may be utilized by the configuration system to manage and control the use of the payment handlers. For example, the configuration system may track whether the payment handler was purchased and/or rented by the merchant, what processor application is associated with the payment handler and whether the processor application has been purchased and/or rented, and whether there is a service contract on the payment handler. Tying the various parameters to unique ID enables the configuration system to control what level of access should be provided to what payment handlers. The configuration system may turn processor application access on or off, or charge for processor applications, depending on the status associate with the unique ID.
  • For example, if the payment handler was purchased with an associated processor application, during installation of the payment handler a merchant account party may access the configuration system and provide the unique ID. The configuration system may look up the status of the unique ID and after validating the status of the unique ID may download a processor application and possibly the merchant profile associated therewith. The access to the configuration system may be via the computing device. The download may be directly to the payment handler.
  • If a merchant account party accesses the configuration system and attempts to load a different processor application onto the payment handler, the configuration system may determine that the unique ID is not associated with that processor application and disallow the load, or allow for it with payment for the new processor application. If a merchant account party attempts to reload the processor application and/or merchant profile for a rented payment handler and/or rented processor application and the rent has not been paid the configuration system may preclude the load until the rent is paid.
  • If the payment handler can not access the merchant profile when it attempts to create an electronic payment transaction it may send the configuration system a request for a down load of the merchant profile where the request includes the unique ID. The configuration system validates the unique ID and determines the merchant profile associated therewith and downloads the merchant profile to the payment handler. The configuration system may automatically download the appropriate processor application with the merchant profile.
  • If the payment handler experiences problems, the merchant account party (possibly the merchant) may access the configuration system and request that the payment handler be reconfigured (e.g., have merchant profile and/or processor application reloaded).
  • If it is determined that the merchant profile needs to be recreated, a merchant account party may access the configuration system and create the new merchant profile and have the new profile downloaded to the payment handler (the associated processor application may also be downloaded).
  • If it is determined that there is a problem with the payment handler and that a new unit is required, a merchant account party may access the configuration system and change the unique ID associated with the merchant account and then download the appropriate data to the new payment handler. The new payment handler preconfigured can be delivered to the merchant for installation. The unique ID of the old payment handler may remain associated with the merchant in an inactive state until the merchant returns the payment handler. If the merchant doesn't return the unit they may be charged accordingly. Once the payment handler is returned it may be disassociated with the merchant. If the returned payment handler is repaired the unique ID may be reprogrammed and the unit may be made available for a new merchant. The unique ID is reprogrammed rather releasing the existing unique ID in order to avoid inadvertent processing of transactions for the new merchant to the old merchant.
  • A merchant account may provide limited reloads and/or reconfigures unless a service agreement is purchased. When a merchant account party attempts to reload and/or reconfigure a payment handler the configuration system may determine if a service agreement is in place for the unique ID. If a service agreement is in place the configuration system may allow reloading/reconfiguring. If a service agreement is not in place and the number of reloads/reconfigurations has been exceeded the configuration system may not allow the reload/reconfiguration, may charge for the reload/reconfiguration or may provide the option to purchase a service agreement.
  • The remote access to the configuration system by merchant account parties to create merchant profiles and to load the merchant profiles and/or the processor applications expedites the creation, configuration and troubleshooting time. The use of the unique ID makes access to the appropriate account easier and also provides the configuration system with additional management and control over the payment handlers and the merchant accounts.
  • According to one embodiment, a processing switch (multi merchant processing server (MMPS)) is utilized to receive electronic payment transactions that are only identified by the unique ID, look up the merchant profile and processing application associated with the unique ID, and reconfigure the electronic payment transactions to include the associated merchant profile prior to forwarding the electronic payment transactions to the payment processing system. Accordingly, the payment handlers need not have the merchant profile loaded therein. Furthermore, the payment handlers may contain the same processor application regardless of what payment processing system is processing the electronic payment transactions. The processor application may create and format the electronic payment messages in a format that may be processed by the processing switch. The processing switch may have various processor applications stored therein that define the different formats necessary for creating electronic payment transactions for the payment processing systems that it supports.
  • FIG. 5 illustrates an example architecture used to process electronic payments for merchant transactions. The architecture includes the merchant system 510, the payment handler 520 having a unique ID, the communication network 530, the processing switch (MMPS) 540, and the payment processing system 550.
  • The payment handler 520 may receive transaction data (payment amount) and electronic payment information and process the information to create an electronic payment transaction. The payment handler 520 may add the unique ID in the electronic payment transactions. The unique ID may be embedded into the electronic payment transaction or may be included in header data for the electronic payment transaction message. The payment handler 520 does not require programming/configuration of the merchant profile and does need not to have memory for storing the merchant profile.
  • The processing switch 540 may store client side merchant profiles for various merchant accounts (and associated merchants) and may associate the unique ID of the payment handler 520 used by the merchant with the merchant (and their client side merchant profile). The processing switch 540 may receive the electronic payment transactions from the payment handlers 520 having the unique ID included and may look up the unique ID and retrieve the associated merchant profile and associated processor software. The processing switch 540 may then reformat the electronic payment transaction in accordance associated processor software and the merchant profile and forward the reformatted electronic payment transaction to the payment processing system 550.
  • The use of a unique ID for the payment handler 520, and the correlation of the unique ID to the merchant profile in the processing switch 540 enables the configuration required to process electronic payment transactions for a merchant to be moved upstream from the payment handler 520 to the processing switch 540. The formatting of the electronic payment transactions, and inclusion of the merchant profile therein, required by the payment processing system 550 is performed by the processing switch 540 instead of the payment handler 520.
  • The processing switch 540 may provide merchant account parties access thereto to create merchant profiles, to associate the merchant profiles to the unique ID for the associated payment handler 520, and to configure the payment handlers (e.g., download processor application that formats electronic payment transactions for the processing switch). The processing switch 540 may be utilized to manage and control the use of the payment handlers 520 as described above with respect to the configuration system 150.
  • FIG. 6 illustrates an example process flow for processing electronic payment transactions using the example architecture of FIG. 5. Initially the merchant system processes a transaction for a customer 600. Electronic payment information (e.g., credit card number) is received from the customer to pay for the transaction 610. The transaction information (payment amount) and the electronic payment information are provided to the payment handler where the information is processed and the unique ID associated therewith is added to create an electronic payment transaction and the electronic payment transaction is forwarded to the processing switch 620. The payment handler may be configured to communicate with the processing switch.
  • The processing switch extracts the unique ID and looks up the merchant profile associated therewith 630. The processing switch then reformats the electronic payment transaction in accordance with the merchant profile 640. The reconfiguration includes removing the unique ID and adding the data that the payment processing system requires in order to validate and process the electronic payment. The reformatted electronic payment transaction is provided to the payment processing system where the electronic transactions are processed 650.
  • The payment handlers described above with respect to FIGS. 1-6 may be provided in various different configurations. The configurations may be based on the type of merchant system and communication network being utilized. The payment handlers may have a unique ID associated therewith. The payment handlers may include memory and have the merchant profile and processor application stored therein if the electronic payment transactions are formatted for and provided to the payment processing system.
  • FIGS. 7A-D illustrate several example merchant system-hardware payment handler configurations. FIG. 7A illustrates an example configuration where the communications network 730 utilized is the public switched telephone network (PSTN). The payment handler 720 (DialTran) may include a processor to process the transactions and a telephone modem (communication device) and a telephone jack (output interface) to transmit the transactions over the PSTN 730. For ease of illustration, the processor, the modem, and the jack are not illustrated. A telephone cable may be used to connect the DialTran payment handler 720 to the PSTN 730. Alternatively the telephone modem may be separate from the DialTran 720 and connected thereto. As there are a plurality of different modems that utilize different operational parameters configuration problems may occur in this alternative embodiment. Accordingly, the DialTran 720 may be configured to work with a select number of modems and the system will only be guaranteed to work (avoid configuration problems) with one of the select modems.
  • FIG. 7B illustrates an example configuration where the communications network 730 utilized is the Internet. The payment handler 720 (IPTran) may include a processor (not separately illustrated) to process the transactions and break the data into packets for transmission over the Internet 730. The IPTran payment handler 720 may be physically connected to a DSL data modem and/or router (DSL/Cable router/modem) 722 via an Ethernet cable or may have a wireless connection therebetween. The DSL/Cable router/modem 722 may provide connectivity to the Internet 730 via telephone or coaxial cable. As there are a plurality of different modems/routers 722 that utilize different operational parameters configuration problems may occur. Accordingly, the IPTran 720 may be configured to work with a select number of modems/routers for each type of Internet connection (e.g., DSL, cable) and the system will only be guaranteed to work (avoid configuration problems) with one of the select modems/routers. Alternatively, the DSL/cable router/modem 722 may be included within the IPTran 720. A DSL IPTran may include a DSL modem/router and a cable IPTran may include a cable modem router.
  • FIG. 7C illustrates an example configuration where the communications network 730 utilized is the Internet. A wireless communication device 724 (e.g., wireless network card) is used to provide wireless connectivity between the IPTran 720 and the Internet 730. Using a wireless network may be beneficial for mobile merchant systems or systems located where it may be difficult or costly to run wired telephone or Internet lines. As there are a plurality of different wireless communication devices that utilize different operational parameters configuration problems may occur. Accordingly, the IPTran 720 may be configured to work with a select number of wireless communication devices and the system will only be guaranteed to work (avoid configuration problems) with one of the select ones. Alternatively the wireless communication device 724 may be within the IPTran 720.
  • The merchant may desire to utilize more than one communication network for processing electronic payments (e.g., redundant networks for fallback processing). For example, the merchant may utilize the Internet as their primary communications network and the PSTN as their redundant network if Internet connection is lost. The merchant may desire to connect to the communications network in more than one fashion (e.g., wired and wireless). For example, if the merchant moves the merchant system to a remote location they may switch from connecting to the Internet via a DSL/cable modem/router to a wireless connection. The merchant could utilize multiple payment handlers to enable communications over multiple communication networks (e.g., PSTN, Internet) or to provide multiple connections (e.g., wired, wireless) to the communications network. For example the merchant may have an IPTran for Internet communications and DialTran for PSTN communications.
  • Preferably, the payment handler may be capable of utilizing more than one communication network or more than one connection to process electronic payment transactions. The payment handler may automatically switch from communicating over the primary communication network to the secondary network if there is a problem/failure with the primary network. The payment handler may also permit the merchant to selectively switch between which communication network is utilized or between how the connection to the communication network is established.
  • FIG. 7D illustrates an example configuration where the primary communications network 730 utilized is the Internet with the PSTN as the fallback. The payment handler 720 may be a combination of a dial link modem and an IPTran with functionality for automatically switching upon an error in the IPTran or the Internet connection or to allow manual switchover (TwinTran).
  • FIGS. 8A-B illustrate several example software merchant system-software payment handler configurations. FIG. 8A illustrates an example configuration where the software merchant system 810 (e.g., point of sale (POS) application) and the software payment handler 820 (epay) are running and interfaced together on the same device (e.g., computer) 812. The unique ID used to identify the ePay 820 may be a serial number associated with the ePay 820 or may be a MAC ID associated with the device 812 the software is running on. The merchant system 810 and the ePay 820 are not limited to running on the same device. Rather, the merchant system 810 and the ePay 820 could be run on separate devices capable of communicating with one another without departing from the current scope. In fact, several merchant systems 810 could be networked to a single ePay 820.
  • The ePay 820 may configure the data for processing by the processor switch 840. The device 812 may be connected to a communication device (e.g., modem, DSL/Cable router/modem, wireless network card) 826 for providing connectivity to the communication network 830 (e.g., PSTN, Internet). The device 812 may be wired to the communication device 826 (e.g., via an Ethernet cable) or may have a wireless connection therebetween. Alternatively, the communication device 826 may be included within the device 812.
  • Like the hardware merchant system it is possible for the software merchant system to have redundant paths to communicate with the processor switch 840. For example, if the device 812 has multiple communication devices available to it, redundant communication paths can exist between the ePay 820 and the payment processing center 850.
  • FIG. 8B illustrates an example configuration having a modem 328 to communicate with the PSTN 830, and a DSL/Cable router/modem 822 and a wireless network card 824 to communicate with the Internet 830. The merchant system 810 and the ePay 820 may be loaded on the same device or different devices. The modem 828, the DSL/Cable router/modem 822 and/or the wireless network card 824 may be contained within the device having the ePay 820 loaded thereon or on separate devices or may be standalone devices.
  • Although the disclosure has been illustrated by reference to specific embodiments, it will be apparent that the disclosure is not limited thereto as various changes and modifications may be made thereto without departing from the scope. Reference to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described therein is included in at least one embodiment. Thus, the appearances of the phrase “in one embodiment” or “in an embodiment” appearing in various places throughout the specification are not necessarily all referring to the same embodiment.
  • An embodiment may be implemented by hardware, software, firmware, microcode, or any combination thereof. When implemented in software, firmware, or microcode, the elements of an embodiment are the program code or code segments to perform the necessary tasks. The code may be the actual code that carries out the operations, or code that emulates or simulates the operations. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
  • The program or code segments may be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The “processor readable or accessible medium” or “machine readable or accessible medium” may include any medium that can store, transmit, or transfer information. Examples of the processor/machine readable/accessible medium include an electronic circuit, a semiconductor memory device, a read only memory (ROM), a flash memory, an erasable ROM (EROM), a floppy diskette, a compact disk (CD-ROM), an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.
  • The code segments may be downloaded via computer networks such as the Internet, Intranet, etc. The machine accessible medium may be embodied in an article of manufacture. The machine accessible medium may include data that, when accessed by a machine, cause the machine to perform the operations described in the following. The term “data” here refers to any type of information that is encoded for machine-readable purposes. Therefore, it may include program, code, data, file, etc.
  • All or part of an embodiment may be implemented by software. The software may have several modules coupled to one another. A software module is coupled to another module to receive variables, parameters, arguments, pointers, etc. and/or to generate or pass results, updated variables, pointers, etc. A software module may also be a software driver or interface to interact with the operating system running on the platform. A software module may also be a hardware driver to configure, set up, initialize, send and receive data to and from a hardware device.
  • An embodiment may be described as a process which is usually depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
  • The various embodiments are intended to be protected broadly within the spirit and scope of the appended claims.

Claims (10)

1. A method for creating a merchant profile that includes data required by a payment processor to process electronic payment transactions for a merchant, the method comprising
providing parties associated with a merchant account access to a configuration system;
accepting input from the merchant account parties related to the merchant account between the payment processor and the merchant;
validating the input;
notifying the merchant account parties if any required information is missing or invalid;
processing the input to create the merchant profile; and
storing the merchant profile for the merchant.
2. The method of claim 1, wherein the accepting input includes providing a user interface for the payment processor to enter the input.
3. The method of claim 2, wherein the user interface is a webpage.
4. The method of claim 1, wherein the accepting input includes receiving a file containing information related to the merchant account.
5. The method of claim 1, further comprising down-loading the merchant profile to be stored on a payment handler that is used to process electronic payment transactions for the merchant.
6. The method of claim 1, further comprising associating the merchant profile with a unique ID for a payment handler used to process electronic payment transactions for the merchant.
7. The method of claim 6, wherein the associating includes accepting data regarding the association of the unique ID and the merchant profile from the merchant account parties.
8. The method of claim 6, further comprising
receiving a request for the merchant profile for a merchant, wherein the request is identified by the unique ID for the payment handler associated with the merchant;
retrieving the merchant profile associated with the unique ID; and
down-loading the merchant profile to be stored on the payment handler.
9. The method of claim 7, further comprising
receiving a request for a processor application, wherein the request is identified by the unique ID for the payment handler associated with the merchant;
retrieving the processor application associated with the unique ID; and
down-loading the processor application to be stored on the payment handler.
10. The method of claim 6, further comprising
receiving an electronic payment transaction identified by unique ID;
retrieving the merchant profile associated with the unique ID;
reformatting the electronic payment transaction to include the merchant profile; and
forwarding the reformatted electronic payment transaction to the payment processor.
US12/357,278 2006-12-19 2009-01-21 Electronic payment processing system Abandoned US20090132418A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/357,278 US20090132418A1 (en) 2006-12-19 2009-01-21 Electronic payment processing system

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US87064206P 2006-12-19 2006-12-19
US11/959,926 US7814013B2 (en) 2006-12-19 2007-12-19 Electronic payment processing system
US12/357,278 US20090132418A1 (en) 2006-12-19 2009-01-21 Electronic payment processing system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/959,926 Division US7814013B2 (en) 2006-12-19 2007-12-19 Electronic payment processing system

Publications (1)

Publication Number Publication Date
US20090132418A1 true US20090132418A1 (en) 2009-05-21

Family

ID=39528726

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/959,926 Active US7814013B2 (en) 2006-12-19 2007-12-19 Electronic payment processing system
US12/357,278 Abandoned US20090132418A1 (en) 2006-12-19 2009-01-21 Electronic payment processing system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/959,926 Active US7814013B2 (en) 2006-12-19 2007-12-19 Electronic payment processing system

Country Status (1)

Country Link
US (2) US7814013B2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100274726A1 (en) * 2008-09-19 2010-10-28 Logomotion, S.R.O system and method of contactless authorization of a payment
US20100274677A1 (en) * 2008-09-19 2010-10-28 Logomotion, S.R.O. Electronic payment application system and payment authorization method
US20110022482A1 (en) * 2009-05-03 2011-01-27 Logomotion, S.R.O. Payment terminal using a mobile communication device, such as a mobile phone; a method of direct debit payment transaction
US20110042456A1 (en) * 2009-04-24 2011-02-24 Logomotion, S.R.O. Method and System of Electronic Payment Transaction, In Particular By Using Contactless Payment Means
US20110053556A1 (en) * 2009-02-27 2011-03-03 Logomotion, S.R.O. Computer Mouse For Secure Communication With A Mobile Communication Device
US20110057025A1 (en) * 2009-09-04 2011-03-10 Paycode Systems, Inc. Generation, management and usage of on-demand payment ids
US20110196796A1 (en) * 2008-09-19 2011-08-11 Logomotion, S.R.O. Process of selling in electronic shop accessible from the mobile communication device
US20120078736A1 (en) * 2010-09-08 2012-03-29 Paycode Systems, Inc. On-demand generation of tender ids for processing third-party payments via merchant pos systems
US8825798B1 (en) 2012-02-02 2014-09-02 Wells Fargo Bank N.A. Business event tracking system
US20160071174A1 (en) * 2011-06-28 2016-03-10 Amazon Technologies, Inc. Modifying configurations associated with a hosted electronic platform environment

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050229003A1 (en) 2004-04-09 2005-10-13 Miles Paschini System and method for distributing personal identification numbers over a computer network
US10205721B2 (en) 2002-12-10 2019-02-12 Ewi Holdings, Inc. System and method for distributing personal identification numbers over a computer network
WO2004107280A2 (en) 2003-05-28 2004-12-09 Ewi Holdings, Inc. System and method for electronic prepaid account replenishment
US7280644B2 (en) 2004-12-07 2007-10-09 Ewi Holdings, Inc. Transaction processing platform for faciliating electronic distribution of plural prepaid services
US11475436B2 (en) 2010-01-08 2022-10-18 Blackhawk Network, Inc. System and method for providing a security code
US11599873B2 (en) 2010-01-08 2023-03-07 Blackhawk Network, Inc. Systems and methods for proxy card and/or wallet redemption card transactions
US8175938B2 (en) 2004-04-13 2012-05-08 Ebay Inc. Method and system for facilitating merchant-initiated online payments
US10296895B2 (en) 2010-01-08 2019-05-21 Blackhawk Network, Inc. System for processing, activating and redeeming value added prepaid cards
US20090254428A1 (en) * 2008-04-03 2009-10-08 First Data Corporation Systems and methods for delivering advertising content to point of sale devices
US20100077464A1 (en) * 2008-09-23 2010-03-25 Visa Usa, Inc. Merchant device and method for support of merchant data processing
US8744998B2 (en) * 2008-08-28 2014-06-03 Visa Usa, Inc. FTP device and method for merchant data processing
US8527474B2 (en) * 2008-08-28 2013-09-03 Visa Usa, Inc. Acquirer device and method for support of merchant data processing
US20100057742A1 (en) * 2008-08-28 2010-03-04 Visa Usa, Inc. Mrw interface and method for support of merchant data processing
US8341084B2 (en) 2009-06-08 2012-12-25 Mastercard International Incorporated Method, apparatus, and computer program product for topping up prepaid payment cards for offline use
US20110276420A1 (en) * 2008-09-17 2011-11-10 Robert White Cash card system
US10037526B2 (en) * 2010-01-08 2018-07-31 Blackhawk Network, Inc. System for payment via electronic wallet
CA2786264A1 (en) 2010-01-08 2011-07-14 Blackhawk Network, Inc. A system for processing, activating and redeeming value added prepaid cards
US10755261B2 (en) 2010-08-27 2020-08-25 Blackhawk Network, Inc. Prepaid card with savings feature
US20120209771A1 (en) * 2011-02-14 2012-08-16 Jeffrey Winner Monitoring for offline transactions
US9111406B2 (en) 2011-11-25 2015-08-18 International Business Machines Corporation Multi-point capacitive information transfer
CN104054098A (en) * 2012-01-13 2014-09-17 电子湾有限公司 Systems, methods, and computer program products providing payment in cooperation with EMV card readers
US9141985B1 (en) * 2012-03-01 2015-09-22 Amazon Technologies, Inc. Simplified seller listing service
US11042870B2 (en) 2012-04-04 2021-06-22 Blackhawk Network, Inc. System and method for using intelligent codes to add a stored-value card to an electronic wallet
WO2014081822A2 (en) 2012-11-20 2014-05-30 Blackhawk Network, Inc. System and method for using intelligent codes in conjunction with stored-value cards
US20140289130A1 (en) * 2013-03-25 2014-09-25 iAXEPT Ltd Secure remotely configurable point of sale terminal
GB2536012A (en) * 2015-03-03 2016-09-07 iAXEPT Ltd Remote transaction system, method and point of sale terminal
JP6572884B2 (en) * 2014-04-04 2019-09-11 セイコーエプソン株式会社 POS system and control method of POS system
US10187447B1 (en) 2016-01-28 2019-01-22 Twitter, Inc. Method and system for online conversion attribution
US10055769B1 (en) * 2015-04-30 2018-08-21 Square, Inc. Automatic invoice generation
US10475011B1 (en) 2015-04-30 2019-11-12 Square, Inc. Automatic invoice notification
US10817857B2 (en) * 2016-06-16 2020-10-27 Mastercard International Incorporated Systems and methods for providing multiple communications network options

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6135349A (en) * 1999-02-01 2000-10-24 First Data Corporation System and method for enabling a merchant to apply for a credit card processing account using the internet
US20030101145A1 (en) * 2001-11-27 2003-05-29 Ming-Sum Fang Apparatus and method for downloading configuration data to card terminals and for viewing activity at card terminals
US20060085275A1 (en) * 2002-01-16 2006-04-20 Stokes Patricia L System and method for facilitating online transactions
US20060129483A1 (en) * 2002-06-28 2006-06-15 Philip Course Method for transacting a trade electronically, and a system therefor
US20060212407A1 (en) * 2005-03-17 2006-09-21 Lyon Dennis B User authentication and secure transaction system
US20070150537A1 (en) * 2005-12-24 2007-06-28 Graham Brian T Social network e-commerce and advertisement tracking system
US20080011825A1 (en) * 2006-07-12 2008-01-17 Giordano Claeton J Transactions using handheld electronic devices based on unobtrusive provisioning of the devices

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5812668A (en) * 1996-06-17 1998-09-22 Verifone, Inc. System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture
US7086584B2 (en) * 1999-08-09 2006-08-08 First Data Corporation Systems and methods for configuring a point-of-sale system
US7017012B2 (en) * 2002-06-20 2006-03-21 Sun Microsystems, Inc. Distributed storage cache coherency system and method
US20070050751A1 (en) * 2005-08-31 2007-03-01 Microsoft Corporation Automatic interoperation with legacy POS service and control objects

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6135349A (en) * 1999-02-01 2000-10-24 First Data Corporation System and method for enabling a merchant to apply for a credit card processing account using the internet
US20030101145A1 (en) * 2001-11-27 2003-05-29 Ming-Sum Fang Apparatus and method for downloading configuration data to card terminals and for viewing activity at card terminals
US20060085275A1 (en) * 2002-01-16 2006-04-20 Stokes Patricia L System and method for facilitating online transactions
US20060129483A1 (en) * 2002-06-28 2006-06-15 Philip Course Method for transacting a trade electronically, and a system therefor
US20060212407A1 (en) * 2005-03-17 2006-09-21 Lyon Dennis B User authentication and secure transaction system
US20070150537A1 (en) * 2005-12-24 2007-06-28 Graham Brian T Social network e-commerce and advertisement tracking system
US20080011825A1 (en) * 2006-07-12 2008-01-17 Giordano Claeton J Transactions using handheld electronic devices based on unobtrusive provisioning of the devices

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110196796A1 (en) * 2008-09-19 2011-08-11 Logomotion, S.R.O. Process of selling in electronic shop accessible from the mobile communication device
US20100274677A1 (en) * 2008-09-19 2010-10-28 Logomotion, S.R.O. Electronic payment application system and payment authorization method
US9098845B2 (en) * 2008-09-19 2015-08-04 Logomotion, S.R.O. Process of selling in electronic shop accessible from the mobile communication device
US8799084B2 (en) 2008-09-19 2014-08-05 Logomotion, S.R.O. Electronic payment application system and payment authorization method
US20100274726A1 (en) * 2008-09-19 2010-10-28 Logomotion, S.R.O system and method of contactless authorization of a payment
US20110053556A1 (en) * 2009-02-27 2011-03-03 Logomotion, S.R.O. Computer Mouse For Secure Communication With A Mobile Communication Device
US20110042456A1 (en) * 2009-04-24 2011-02-24 Logomotion, S.R.O. Method and System of Electronic Payment Transaction, In Particular By Using Contactless Payment Means
US8500008B2 (en) 2009-04-24 2013-08-06 Logomotion, S.R.O Method and system of electronic payment transaction, in particular by using contactless payment means
US20110112968A1 (en) * 2009-05-03 2011-05-12 Logomotion, S.R.O. Pos payment terminal and a method of direct debit payment transaction using a mobile communication device, such as a mobile phone
US8406809B2 (en) 2009-05-03 2013-03-26 Logomotion, S.R.O. Configuration with the payment button in the mobile communication device, the way the payment process is started
US8606711B2 (en) 2009-05-03 2013-12-10 Logomotion, S.R.O. POS payment terminal and a method of direct debit payment transaction using a mobile communication device, such as a mobile phone
US20110021175A1 (en) * 2009-05-03 2011-01-27 Logomotion, S.R.O. Configuration with the payment button in the mobile communication device, the way the payment process is started
US20110022482A1 (en) * 2009-05-03 2011-01-27 Logomotion, S.R.O. Payment terminal using a mobile communication device, such as a mobile phone; a method of direct debit payment transaction
US10332087B2 (en) 2009-05-03 2019-06-25 Smk Corporation POS payment terminal and a method of direct debit payment transaction using a mobile communication device, such as a mobile phone
US20110057025A1 (en) * 2009-09-04 2011-03-10 Paycode Systems, Inc. Generation, management and usage of on-demand payment ids
US20120078736A1 (en) * 2010-09-08 2012-03-29 Paycode Systems, Inc. On-demand generation of tender ids for processing third-party payments via merchant pos systems
US20160071174A1 (en) * 2011-06-28 2016-03-10 Amazon Technologies, Inc. Modifying configurations associated with a hosted electronic platform environment
US9934524B2 (en) * 2011-06-28 2018-04-03 Amazon Technologies, Inc. Modifying configurations associated with a hosted electronic platform environment
US8825798B1 (en) 2012-02-02 2014-09-02 Wells Fargo Bank N.A. Business event tracking system

Also Published As

Publication number Publication date
US7814013B2 (en) 2010-10-12
US20080147552A1 (en) 2008-06-19

Similar Documents

Publication Publication Date Title
US7814013B2 (en) Electronic payment processing system
US8666892B2 (en) Electronic payment processing system
US9866989B2 (en) Payment application download to mobile phone and phone personalization
RU2323477C2 (en) System and method for purchasing goods and services through access stations for accessing data transmission network using a network of trading terminals
US7658323B2 (en) Point-of-service (POS) and POS application compatability
US8676672B2 (en) Systems and methods for electronic delivery of stored value
TWI354235B (en) Apparatus for supporting mobile payment processing
US7861238B2 (en) Configuration tool and method of updating an archive file property relating to at least one point-of-sale peripheral
CN102867377B (en) Method and system for realizing services on point-of-sale (POS) terminal machine and POS terminal machine
EP1302881A1 (en) Order processing system and method
US9286049B2 (en) Systems, methods, and computer program products for managing service installation
EP2404237A1 (en) Issuing systems, acquiring systems, and payment networks/systems development
CN106096456A (en) The software of link pre-installation and the system and method for the user account of online shop
CN108027743B (en) Isolated applications with segmented architecture
CN103312680B (en) The moving method of a kind of NFC terminal application, Apparatus and system
US20180025337A1 (en) Standardizing point of sale services and leveraging instances of the plu data
CN110348832A (en) B2C online payment gateway adapter, system, adaptation and method of payment
US11710117B1 (en) Systems and methods for EMV terminal device testing using EMV card emulation
US7483863B2 (en) Electronic commerce information processing system and method
KR101771487B1 (en) Electronic Payment System Based on Application and Method thereof
US20240062633A1 (en) Method of interconnecting teller computing device with peripherals in a bank branch
CN114581088A (en) Aggregated payment method, device and system for SaaS (software as a service) system
JP2002042035A (en) Order price demanding processing system and method therefor
CN111383404A (en) Preferential activity settlement system and method based on POS machine
CN104867003A (en) Apparatus To Manage Mobile Payment Account Settlement

Legal Events

Date Code Title Description
AS Assignment

Owner name: DATACAP SYSTEMS, INC., PENNSYLVANIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MORSILLO, LEON N., MR.;ZEIGLER, TERRY H., MR.;REEL/FRAME:025362/0544

Effective date: 20101028

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION