HK1166871B - Payment system - Google Patents

Abstract

Embodiments of the invention provide a method of processing payment authorisation requests for payment transactions to be conducted via a data communications network on behalf of online merchants, the payment authorisation requests being conducted as a result of orders by financial instrument holders via a plurality of different online merchant systems, each of said online merchants having an online merchant identity. The method is conducted by a trusted central intermediary system which is arranged to transmit payment authorisation requests to each of a plurality of different online merchant Internet Payment Service Provider (IPSP) systems; each merchant IPSP system is arranged to transmit payment authorisation requests to at least one of a plurality of acquiring bank payment processor systems, and each of said plurality of acquiring bank payment processor systems is responsible for processing payment authorisations for at least one of said acquiring banks. The method comprises: receiving from a first online merchant system, responsible for originating payment authorisation requests for a first online merchant, a payment authorisation request relating to authorisation of a payment transaction, said received payment authorisation request being initiated as a result of a financial instrument holder conducting an order via the first online merchant system; in response to receiving said request: a) generating a payment authorisation request comprising transaction data including: i) a financial instrument identity to be used in the payment transaction by the financial instrument holder; and ii) an online merchant identity, associated with the first online merchant, as the payment transaction beneficiary; and iii) one or more transaction details including a payment amount; and b) retrieving transmission data to enable the transmission of payment authorisation request data to a selected merchant IPSP system associated with the first online merchant; and on the basis of the retrieved transmission data, transmitting said generated payment authorisation request to the selected merchant IPSP system, wherefrom a further payment authorisation request may be generated and transmitted to an acquiring bank payment processor system responsible for processing payment authorisations for the acquiring bank with which the first online merchant is associated. Embodiments of the invention enable a user to select a payment method on a per transaction basis, whilst removing the requirement for the user to provide payment details to individual online merchant systems or to their merchant IPSP systems. Thus, providing that online merchants, or their merchant IPSPs, subscribe to a service arranged to perform the method, users only have to submit their respective payment details, preferably only once, to a separate, trusted entity.

Description

Payment system

Technical Field

The present invention relates to a system and method for processing payment authorisation requests for payment transactions to be conducted via a data communications network on behalf of online merchants, particularly but not exclusively suitable for processing orders placed by financial instrument holders (financial instrument holders).

Background

Users are increasingly encouraged to shop online, i.e., via the internet and related technologies. Generally, existing online payment systems fall into one of three categories of settings: in a first type of arrangement, the online merchant system collects payment details from the financial instrument holder (alternatively referred to as the buyer or cardholder) without the buyer directly processing any other entities that may be involved in the transaction, and the online merchant system sends the transaction details directly to its acquiring bank system. In a second type of arrangement, the online merchant system collects payment details from the purchaser without the purchaser having to directly process any other entities that may be involved in the transaction, and the online merchant system sends the transaction details directly to an online merchant Internet Payment Service Provider (IPSP) that handles payment authorization on behalf of the merchant. The merchant IPSP system then transmits the details to the online merchant's acquiring bank system; the details may be transmitted directly to the acquiring bank or to a payment processor operating on behalf of the acquiring bank. Examples of IPSP systems providing support for this second type of setup include Protx^TMVeri-Secure Payment System (VSP).

In both the first and second types of settings, the online merchant system typically obtains payment card data, bank account information, and/or other financial data from the purchaser. The online merchant system then passes this information to the acquiring bank processing system either directly or via the merchant IPSP system. The acquiring bank assigns an online merchant account identifier to each online merchant system and this account identifier is used to identify the online merchant to the acquiring bank when requesting authorization for the transaction.

Fig. 1 shows an example of a conventional online payment system according to a second type of arrangement, comprising a plurality of online merchant systems 1a, 1b, 1 c. In this arrangement, each online merchant is operatively associated with an online merchant Internet Payment Service Provider (IPSP) system 3, the merchant IPSP system 3 being a payment gateway that the online merchant selects and subscribes to for secure transactions over the internet. Although this figure shows each of the online merchant systems 1a.. 1c associated with the same merchant IPSP system 3, it is optional and often in practice that the online merchant systems are linked to different merchant IPSP systems 3. Each merchant IPSP system 3 provides a system for communicating payment card data, authorization requests and authorization responses over the internet using cryptographic techniques. The transaction information is sent by the merchant IPSP system 3 to the acquiring bank 5 via a data communications link and from there to a card scheme system (card scheme) 7 between the issuing bank where the card is checked for validity and the availability of funds on the account is verified. Returning the authorization code to the merchant IPSP system 3; the authorization is encrypted by the merchant IPSP system 3 and transmitted in encrypted form to the online merchant system 1a which triggers the order to be completed.

A conventional end-to-end online transaction using the second type of arrangement and involving the entities shown in fig. 1 involves the following steps:

the system 1a website of the online merchant collects one or more order selections from the customer. The buyer checks out, enters its payment details and places an order at the system 1a website of the online merchant by pressing the "submit order" or equivalent button on the order sending webpage of the merchant website.

The buyer's web browser encrypts information to be sent between the browser and the online merchant's web server.

The online merchant then forwards the transaction details to its merchant IPSP system 3, typically via another encrypted connection to a payment server hosted by the merchant IPSP system 3.

The merchant IPSP system 3 forwards transaction information including the internet account identifier of the online merchant to a processor for use by the online merchant's acquiring bank system 5.

Processor 5 forwards the transaction information to a payment planning system 7 (e.g., Visa/MasterCard).

The payment planning system 7 routes the transaction to the correct card issuing bank system 9.

The payment card issuing bank system 9 receives the authorisation request and sends a response back to the processor of the online merchant's acquiring bank system 5 with a response code.

The processor of the online merchant's acquiring bank system 5 forwards the response to the merchant IPSP system 3.

The merchant IPSP system 3 receives the response and forwards the response to the system of the online merchant which interprets the response, and the relevant response is then passed back to the purchaser via the merchant, confirming that the transaction is authorised.

Merchant IPSP system 3 submits the approved authorizations of all online merchants to the online merchant's acquiring bank system 5 for settlement on behalf of the online merchants.

The acquiring bank system 5 deposits the sum of the approved funds minus any remuneration and fees into the designated account of the online merchant. The account may be an account of the same bank, in the case of an online merchant conducting its banking with the acquiring bank, or may be an account of another bank.

An advantage of using a payment gateway such as the merchant IPSP system shown in figure 1 is that the merchant IPSP system may provide one or more additional various transaction processing functions on behalf of the online merchant, such as settlement (settlement), declination (chargebacks), refund (refunds), and transaction reporting. In the settlement procedure, the merchant IPSP system 3 submits the approved authorizations of all online merchants collected over a given period of time "in bulk" to the online merchants' acquiring bank system 5 for settlement. A repudiation is the reversal of a payment card transaction initiated by the purchaser or the bank issuing the payment card used in the purchase. This is in contrast to a refund that an online merchant approves and initiates via the merchant IPSP system 3. The transaction reports include summary reporting functionality provided for accumulated transactions authorized and optionally settled by the merchant IPSP system 3 so that a merchant can, for example, select a data range and view the summary involved in all transactions conducted within the selected data range. The merchant IPSP system 3 may provide the online merchant with a secure online website whereby to approve a repudiation, initiate a refund, and/or view a transaction report as described.

However, in each of the first and second types of payment systems described above, the purchaser is required to provide his or her payment information separately for transactions initiated with each of the different online merchants. Thus, for each new online merchant with which the buyer interacts, the risk of exposing, abusing, and/or fraudulent use of the buyer's financial data increases.

In a third type of arrangement (not shown), the online merchant system redirects the buyer to an alternate payment system website with which the buyer interacts to complete the transaction. The alternative payment system interacts directly with the user who provides payment to the alternative payment system either directly from his bank account or via a device such as a payment card. In the case of using a payment card from a conventional payment plan, the alternative payment system performs the role of a merchant in the conventional payment system, submitting payment requirements through the acquirer system. A payment is made from the user to the alternative payment system. The alternative payment system is then responsible for any reimbursement (reimbursement) by the merchant. In the second case, the alternative payment system essentially acts as a traditional clearing house (clearing house) which reimburses the user's account within the alternative payment system from the actual issuing bank account of the user by directly debiting the account. The alternative payment system then ensures that the payment is sent to the merchant's issuing bank account, typically through a conventional clearing house. This merchant bank account may be the same or different than an account held at the merchant's traditional acquiring system. Payment systems of the third type therefore often act as intermediaries, most often via individual bank accounts of consumers and merchantsTaking actual funds from the user and transferring the funds to the merchant, the third type of payment system may hold the funds as they pass through an account held by the payment system; examples of this third type of payment system include the well-known PayPal^(TM)A payment system. Such payment systems may also have the ability to operate as a traditional IPSP, for example, by providing associated online payment transaction services.

While this type of payment system alleviates the need for a user to establish an individual payment account with each online merchant, the user has a relationship with an alternative payment system and no relationship with the online merchant system; this poses several significant disadvantages: first, online merchants neither receive payment directly from the acquiring bank nor lend themselves to payment assurance based on a payment plan, as there is no direct relationship between the merchant and the card payment plan in these transactions. Second, for transactions effected via card payment, the purchaser does not have visibility of the individual online merchants from whom the product was purchased (rather the card account identifies an alternate payment system entity). Third, because the transaction is with the payment system and not with the online merchant, the purchaser is not protected by the rules of the card design and may not be protected by any applicable consumer protection measures.

Disclosure of Invention

According to at least one embodiment of the present invention, as indicated in the independent claims, a system and method are provided for processing a payment authorization request for a payment transaction to be conducted via a data communication network on behalf of an online merchant. This is achieved by a combination of the features set out in each of the independent claims. The dependent claims thus specify further detailed implementations of the invention.

More particularly, these aspects of the invention provide a method of processing a payment authorization request for a payment transaction to be conducted via a data communications network on behalf of an online merchant, the payment authorization request being executed as a result of orders placed by a financial instrument holder via a plurality of different online merchant systems, each of the online merchants having an online merchant identity and each of the online merchants being associated with one of a plurality of acquiring banks,

wherein the method is implemented by a trusted central intermediary system arranged to transmit payment authorisation requests to each of a plurality of different online merchant Internet Payment Service Provider (IPSP) systems,

each of the merchant IPSP systems being arranged to transmit a payment authorisation request to at least one of a plurality of acquiring bank payment processor systems, each of the plurality of acquiring bank payment processor systems being responsible for processing payment authorisations for at least one of the acquiring banks,

the method comprises the following steps:

receiving a payment authorization request involving authorization of a payment transaction from a first online merchant system responsible for initiating a payment authorization request for a first online merchant, the received payment authorization request being initiated as a result of an order placed by a financial instrument holder via the first online merchant system;

in response to receiving the request:

a) generating a payment authorization request containing transaction data, the transaction data comprising:

i) a financial instrument identity to be used by a financial instrument holder in a payment transaction; and

ii) an online merchant identity associated with the first online merchant as a payee of the payment transaction; and

iii) one or more transaction details including the payment amount; and

b) retrieving the transmission data to enable transmission of the payment authorisation request data to a selected merchant IPSP system associated with the first online merchant; and

based on the retrieved transmission data, the generated payment authorisation request is transmitted to the selected merchant IPSP system from which further payment authorisation requests may be generated and transmitted to an acquiring bank payment processor system responsible for processing payment authorisations for an acquiring bank associated with the first online merchant.

Preferably, the method comprises receiving data indicative of a selection by a financial instrument holder among a plurality of different financial instruments for the payment transaction, and retrieving a financial instrument identity to be used in the generated payment authorisation request based on said indicated selection. The different financial instruments are advantageously held in local storage or user wallets through a credit broker system. Embodiments of the present invention thus enable a financial instrument holder or user to select a payment method on a per transaction basis, while at the same time freeing the user from having to provide payment details to individual online merchant systems or to their merchant IPSP systems. Thus, as long as the online merchant or its merchant IPSP subscribes to the service set to perform this method, the user need only submit their respective payment details to a separate trusted entity, preferably only once. This approach has the benefit of reducing the risk of fraud that may be incurred in connection with the traditional set-up of the system, while allowing the user to conduct transactions faster and more conveniently, because the user is not required to enter personal and financial information with respect to each transaction.

In respect of the totality of the user's wallets with payment instrument details, the credit broker system preferably provides a registration interface for the financial instrument holder whereby the financial instrument holder can provide the financial instrument identity for registering with said credit broker system as stored registration data. In processing the payment authorisation request, the method includes the step of authenticating a financial instrument holder and, in response, retrieving from said stored registration data (preferably from the user's wallet) a registered financial instrument identity to be used in the generated payment authorisation request.

It should be understood that the terms "online merchant," "merchant IPSP system," "trusted intermediary system," and "acquiring bank payment processor system" refer to logical components. Also, each system may be physically implemented separately from the other systems or physically connected to one or more other systems. For example, in a given organization's setting to host a merchant IPSP system and an online merchant, these components may be physically located on the same network, or even integrated as part of a single system. Further still, where a given institution hosts the merchant IPSP system and the acquiring bank payment processor system, these components may be physically located on the same network, or even integrated as part of a single system. In addition, a single institution may host an online merchant, a merchant IPSP system and an acquiring bank payment processing system. Accordingly, embodiments of the present invention include arrangements in which functions performed in the role of IPSP may be performed by an institution that is also a merchant and/or also an acquirer (acquirer).

Because transactions authorized using the system of the present invention are also processed by the merchant IPSP system, online merchants have access to merchant IPSP functionality relating to these transactions using an interface common to the different transaction types. These transaction types may include transaction types initiated by payment authorization requests via the trusted intermediary system, as well as other separately authorized transaction types that may be processed by the IPSP proxy merchant without being passed through the trusted intermediary system. This common interface may include a secure online website.

In at least one arrangement, the trusted intermediary system receives a payment authorization response from the selected merchant IPSP system and transmits a payment authorization response to the first online merchant system in response to receipt. Further, the method includes receiving an online merchant identity from the first online merchant system, the online merchant identity included in an authorization request generated based on the received online merchant identity. Thus, since the trusted intermediary system interacts with, rather than replacing, the online merchant's existing IPSP system, it is the online merchant account identifier that is transmitted to the acquiring bank. As a result, the relationship of such transactions between the buyer and the online merchant brings the benefit that the buyer is protected by the rules of the card design and, in some cases, conforms to any applicable consumer protection. In addition, the merchant IPSP system may provide one or more of a variety of additional transaction processing functions on behalf of the online merchant system, such as settlement, processing of repudiations, processing of refunds, and transaction reporting. In particular, the merchant IPSP system may provide the online merchant with a secure online website for conducting approval repudiations, initiating refunds and/or viewing transaction reports related to authorized transactions at the secure online website through the system of the present invention.

Preferably, the step of retrieving transmission data to enable transmission of payment authorisation request data to a selected merchant IPSP system associated with the first online merchant comprises retrieving a network address of the selected merchant IPSP system based on the merchant IPSP system with which the first online merchant is registered and the step of transmitting said generated payment authorisation request to the selected merchant IPSP system comprises transmitting said generated payment authorisation request based on the retrieved network address. For example, when a given online merchant registers with the credit broker system, the network address is preferably distributed (populated) on a per online merchant basis, thereby providing a convenient, centralized mechanism for controlling the flow of payment authorization requests. Thus, preferably, the trusted intermediary system provides a registration interface for online merchants so that a given online merchant can register with the merchant IPSP system with which the online merchant is associated.

In at least some arrangements, the credit broker system may cooperate with a plurality of issuing authentication systems each responsible for authentication at a different issuing bank, the method including the step of selectively communicating with each issuing authentication system to verify the identity of the financial instrument holder. Such authentication of the user may be performed using known 3-D security methods and may be performed, for example, when the user adds a payment instrument to his user wallet via the aforementioned registration interface.

The user may register with the credit brokerage system via a number of different mechanisms, including: directly registering with the intermediary system; indirect registration by a trusted third party; and redirected via the online banking service to register with the credit brokerage system. With respect to the third alternative, the method includes retrieving a financial instrument identity to be used in the generated payment authorization request based on authentication of the instrument holder by the selected one of the plurality of issuing authentication systems. Thereafter, data is transmitted to the financial instrument holder enabling the financial instrument holder to perform authentication with respect to the selected authentication system and to receive authentication response data from the selected authentication system in response to authentication of the financial instrument holder by the selected issuing authentication system. Further, embodiments of the invention may include receiving data from a selected issuing authentication system indicating an identity of a financial instrument to be used in the generated payment authorization request in response to authentication of a financial instrument holder by the selected issuing authentication system.

According to a further aspect of the present invention there is provided a trusted intermediary system in communication with a plurality of online merchant systems and a plurality of merchant IPSP systems, said trusted intermediary system being arranged to perform the aforementioned trusted intermediary system steps. Further, an online merchant system is provided in communication with the trusted intermediary system and the plurality of merchant IPSP systems, said online merchant system being arranged to perform the aforementioned online merchant system steps. Additionally, a merchant IPSP system in communication with the trusted intermediary system and the plurality of online merchant systems is provided, said merchant IPSP system being arranged to perform the aforementioned merchant IPSP system steps.

Aspects of the invention also provide software distributed among various systems, suitably configured to perform the aforementioned methods.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which description is made with reference to the accompanying drawings.

Drawings

FIG. 1 is a schematic diagram illustrating a conventional payment system;

FIG. 2 is a schematic diagram illustrating a payment system according to an embodiment of the present invention;

FIG. 3 is a schematic flow diagram illustrating data flow during use of the payment system of FIG. 2 in accordance with an embodiment of the present invention;

FIG. 4 is a schematic block diagram illustrating components of the credit brokering system of FIG. 2, according to an embodiment of the present invention; and

fig. 5 is a schematic timing diagram illustrating message flow between selected components of the payment system of fig. 2, according to an embodiment of the present invention.

Detailed Description

As described above, embodiments of the present invention relate to payment systems and methods, and in particular to systems and methods for processing payment authorization requests for payment transactions conducted via a data communications network on behalf of an online merchant. The system includes a novel transaction entity, referred to herein as a credit brokerage system, which cooperates with a conventional payment entity described in the background section with reference to figure 1.

Fig. 2 shows a schematic diagram of a payment system 1 according to an embodiment of the invention. The trusted intermediary system 10 is shown transmitting payment authorisation requests to each of a plurality of different merchant IPSP systems 3a.. 3 c. Each of the online merchant processing systems 1a.. 1c is associated with one of the merchant IPSP systems 3a.. 3c (as indicated by the dashed line L1 for one of the online merchants 1 c) and with one of the acquiring banks 5c (as indicated by the dashed line L2 still for one of the online merchants 1 c). At least some of the merchant IPSP systems 3b, 3c may be arranged to transmit payment authorisation requests to more than one acquiring bank: this reflects the situation that more than one online merchant can process their payments via a given merchant IPSP system; each merchant has an account with a particular acquiring bank.

Further, the order transmission web page of each online merchant system 1a.. 1c website includes what is referred to herein as a "secure payment system" (SSP) as a novel payment option that identifies payments via the credit broker system 10. Other payment options may also be included, including traditional online payment options, so that the purchaser may select payment options that do not involve payment authorization processed through the credit brokering system 10. Such a separate authorized transaction may, for example, include a traditional online payment option in which the purchaser enters their payment details directly into the online merchant system 1c, or directly into the merchant IPSP system 3c, without the use of the trusted intermediary system 10. With respect to such transactions, the trusted intermediary system 10 interacts with, rather than replacing, the online merchant IPSP system 3c, which online merchant IPSP system 3c may be the existing merchant IPSP system of the online merchant at the time of subscribing to the service provided by the trusted intermediary system 10. This is to say that because the payment system according to an embodiment of the present invention involves the addition of the credit broker system 10 within existing and known processing entities, payments may be made via the credit broker system 10 according to conventional methods using the second and third type of arrangements described with additional reference to figure 1, or alternatively.

The credit broker system 10 saves data corresponding to the user (buyer) and the online merchant that has registered with the broker 10 in the database DB1 along with the transaction data. As described in more detail below, database DB1 holds a set of payment details for a user in the form of a set of stored records, referred to herein as a remote memory or user wallet, for convenience; the user may add details of the payment instrument (typically a card and account) from which they may choose to make payment for the transaction, causing the credit broker system to update the contents of the user's remote memory. Since the credit brokerage system 10 holds a range of payment instruments available to the user, the user may select a payment method on a per transaction basis. Thus, if the online merchants subscribe to the credit brokerage system 10, the users need only submit their respective payment details once to a single entity, thereby freeing the users from the need to provide payment details to the various online merchants each time they shop online. This has the benefit of reducing the risk of fraud being incurred as may occur compared to conventional payment system arrangements (such as that shown in figure 1).

Because transaction authorization requests initiated using the trusted intermediary system 10 are passed to and processed by the IPSP system 3c, online merchants can access other various transaction processing IPSP functions related to these transactions via the trusted intermediary system 10. The merchant IPSP system 3c may provide one or more of such additional transaction processing IPSP functions on behalf of the online merchant system 1c, such as settlement, charge rejection (charge), refund (refund) and transaction reporting. Preferably, the merchant IPSP system 3c provides the online merchant with a secure online website to approve a repudiation, initiate a refund and/or view a transaction report for transactions involving authorization through the trusted intermediary system 10.

Furthermore, since transaction authorization requests initiated using the trusted intermediary system 10 are communicated to and processed by the IPSP system 3c, online merchants may access the IPSP functionality involved in these transactions using an IPSP system interface common to the different transaction types (including those authorized via the trusted intermediary system 10, and other individually authorized transaction types that the IPSP may process on behalf of the merchant and that are not communicated via the trusted intermediary system 10). Such individually authorized transactions may include, for example, transactions in which the purchaser enters his payment details directly into the online merchant system 1c, or directly into the merchant IPSP system 3c, for use in payment authorization handled by the merchant IPSP system 1 c.

In addition, the online merchant internet account identifier is transmitted to the acquiring bank 5c by the merchant IPSP system 3c as part of the payment authorisation request. This has the advantage of ensuring that the buyer is protected by the rules of the card plan and in some cases conforms to any applicable consumer protection; in addition, each transaction involving each online merchant may be identified based on the card status of the user.

As can be seen from fig. 2 (in particular, dashed line L3), the credit broker system 10 is connected to the issuing bank system 9a (although only one connection is shown, it is understood that there may be a connection between the credit broker system 10 and any number of issuing bank systems). This connection facilitates the verification of the cardholder (buyer) using well-known 3-D secure authentication mechanisms. A protocol for 3-D security is described in U.S. patent application 10/156271, published under publication number US2002/0194138 in the name of the Visa international service consortium, the entire contents of which are incorporated herein by reference. This protocol uses messages (typically XML messages) sent over a Secure Sockets Layer (SSL) connection, as described in the aforementioned patent publication as the Payer Authentication Service (PAS). This service may be employed when the credit brokering system 10 determines that a given requested transaction corresponds to a predetermined level of risk, which may be the case, for example, where the transaction includes international shipment of high value goods. The tools that perform risk assessment and indeed determine the risk level for a given transaction are described in more detail below.

The card design system 7 is communicatively connected to the credit broker system 10, as schematically shown by the dashed line L4; this means that the credit broker system 10 subscribes to the account updating service (not labeled in figure 2, but described below as part 415d with reference to figure 4) provided by the card planning system 7 and receives updated card information therefrom (for example) when the card is lost, stolen or expired and is therefore re-issued to the user. An example of such a service is the Visa account updater service (VAU), while another example is the Mastercard automatic bill updater. In one arrangement, the interface to the account update service provided by the card design system 7 is a batch orientation: the credit broker system 10 submits a request or requests to the card design system 7 that include details of certain users registered with the system 10. A batch interface is typically used (e.g., Secure File Transfer Protocol (SFTP) or Connect: Direct)^(TM)) The request file is sent to an account update service responsible for gathering details of the reissued card. After a time interval, the credit brokerage system 10 accesses the account update service and collects the response file, thereafter updating the payment instrument locally for the relevant subscribers of the SSP system. Alternatively, the interface may be message-based, so that individual primary account numbers may be verified or updated in real-time. As an alternative to sending the request directly to the card planning system 7, the credit broker system 10 may send the request to a known acquiring bank system 5a.. 5c in imitation of the operation of the online merchant for subsequent forwarding to the card planning system 7.

Referring now to fig. 3, the operation of the payment system 1 according to an embodiment of the invention is described. At step S301, the user completes their shopping experience through the online merchant system of online merchant C, initiates checkout using the online merchant system, and performs virtual checkout, according to conventionally available methods such as commonly available shopping carts and checkout software packages known to the skilled artisan. The user selects "secure payment system" (SSP) as the payment option (S301), causing the online merchant system 1c to transmit an initiate payment authorization request message to the credit broker system 10 (step S303); the initiation request message contains at least a payment amount for the selected item, an online merchant account identifier, and an identifier for the order. The credit brokerage system 10 then transmits a login URL to the user (step S305) prompting the user to log in, or if this is the first time the user selects SSP as a payment option, prompting the user to register with the credit brokerage system 10. Assuming for the purposes of this example that the user has previously registered with the service, the user enters his login credentials (e.g., username, password, or other authentication details, depending on the authentication mechanism utilized by the credit brokering system 10 — step S307).

The credit brokering system 10 then performs a lookup based on the user credentials and the identification details (step S309), retrieves the details from the user remote store originating from the database DB1, and presents the details to the user for selection of a payment method (step S310). Once the desired payment method is selected from the options provided according to the details retrieved from the user remote store, the trusted intermediary system 10 sends a payment authorisation request message to the IPSP system 3c of the online merchant, the payment authorisation request message containing the selected payment instrument details, the required payment amount and the online merchant identifier (step S311). The merchant IPSP system 3C also sends a payment authorisation request to the relevant acquiring bank 5C (step S313), prompting authorisation (or otherwise) of each payment method (step S315), transmission of a response message from the acquiring bank 5C to the merchant IPSP system 3C (step S317). Assuming that the response contains confirmation that payment is authorized, the merchant IPSP system 3C sends a payment success notification message to the trusted intermediary system 10 at step S319. The payment success notification message contains a reference to card plan authorization and a transaction identifier for the card plan transaction.

The credit brokerage system 10 then sends a payment success confirmation message to the online merchant system 1c (step S321), which prompts the online merchant system to confirm the order status to the user (step S323).

It will be appreciated from the foregoing that conventional online merchant systems, including their merchant IPSP system, need to be modified to include a "secure payment system" (SSP) as a payment option and indeed interface with the trusted intermediary system 10. Thus, the merchant IPSP system exposes payment authorization services to the credit broker system 10 which allows payment and settlement by payment instruments (typically cards and bank accounts). It will further be appreciated that because the trusted intermediary system 10 is integrated with many merchant IPSP systems, it contains a plurality of interface forms and protocols (each corresponding to a respective merchant IPSP system). In addition, each online merchant system is configured with an integrated software component, e.g., in the form of a plug-in, that enables the online merchant to integrate with the credit broker system 10 to initiate a payment transaction using the SSP as a payment method.

Details of the construction and processing capabilities of the credit brokering system 10 will now be described with reference to figure 4. The credit brokerage system 10 comprises a display and connection processing component configured to transmit and manage various user-specific and online merchant-specific data; these processing components will be explained in more detail below, but generally they contain the following:

user registration component and data

When a user wishes to register with the credit brokerage system 10, the user is required to complete an account registration process that allows the user to create an account with the SSP service. The account needs to be structured with the appropriate data that can be used to make payments according to the SSP service originating from the online merchant system providing the service.

Once registered, each user has associated with it a set of records that store details of the account that the user wishes to debit when conducting a financial transaction. This may be a bank account, payment card or other account, such as any payment instrument that may be given a unique account reference. The credit brokerage system 10 includes a display component 404 that enables a user to select, add/remove payment instruments from/to the list of payment instruments. In addition the user has an address book entry to hold shipping details; display component 404 enables a user to modify shipping details. Each user has a profile that includes user demographic (demographic) and identification data and that can be modified via the presentation component 404 while user transaction data can be displayed for viewing by the user. As shown in FIG. 4 and explained in more detail below, the credit brokering system 10 may be implemented as a web server, in which case the display component 404 interoperates with the user's browser, allowing user data to be selected and modified in the manner just described. However, user registration with the credit brokerage system 10 may be via any alternative suitable interface.

Registration may be performed via a number of channels:

registration via SSP site-user logs onto the credit broker system 10 website and displays to the user a registration page designed to obtain the user's identity and preferred payment instrument details

Redirect from order system — if the user is in the order system of the online merchant and wishes to make a payment using the SSP option, they need to register if they are not already registered. Redirecting the user to a registration screen associated with the credit brokering system 10 and then back to the system of the online merchant

Register via online banking-assuming the credit brokerage system 10 contains the necessary integration functionality, the user may register an SSP service registration from within their bank online account service.

User authentication assembly

Authentication of the user to enter the credit brokerage system 10 may be performed for the payment transaction according to any one of 3 known authentications listed below:

1-factor authentication-something the user knows (e.g. username and password, password or Personal Identification Number (PIN))

2-factor authentication-such as 1 factor authentication plus something the user has (e.g. identity card, security token, software token, phone or cell phone)

3-factor authentication-such as 2-factor authentication plus something the user is or does (e.g., a fingerprint or retinal pattern, a DNA sequence (there is sufficient definition of classification), signature or voice recognition, a unique biometric signal, or another biometric identifier).

An example of a mechanism that enables authentication is the aforementioned 3-D security service facilitated by the credit broker system 10, the issuing bank prompting the buyer for a password known only to the bank and the buyer. Since the merchant is not aware of the password and is not responsible for obtaining the password, it can be used by the issuing bank as proof that the purchaser is indeed his cardholder.

In one embodiment, the credit brokerage system 10 implements an authentication process. Alternatively, the user may be logged in via their online bank details, in which case the user logs into their online bank account, whereupon the banking system software redirects the user back to the credit brokerage system 10. As a further alternative, authentication may involve an account identification entity that, based on user-specified input, may act as an intermediary and cooperate with the credit brokerage system 10 to make an identification of a user account on behalf of the user.

Online merchant data storage:

the credit broker system 10 stores the online merchant profile and registration data. These data include the online merchant internet account identifier, and the transaction and network identifier of the merchant IPSP system 3c with which the online merchant system is registered. These data are stored so that the trusted intermediary system 10 can communicate with the merchant IPSP system 3c on behalf of the online merchant system and are collectively referred to as merchant IPSP system transfer data, or simply transfer data. In addition, the credit brokerage system 10 comprises a payment authorisation service by which the credit brokerage system 10 makes payments on behalf of the online merchants. Furthermore, because the trusted intermediary system 10 is integrated with many merchant IPSP systems, it contains multiple interface formats and protocols. Details of the relevant formats and protocols for each merchant IPSP system are maintained in the online merchant data store. The aforementioned transmission data thus includes a mapping of a payment authorisation request issued from a given online merchant system to an IPSP identifier, network address and/or network protocol which enables the payment authorisation request to be routed to the relevant merchant IPSP system.

It is therefore recognised that the registration of any given merchant providing SSP service involves that merchant designating the merchant IPSP system to which it subscribes. The trusted intermediary 10 may conveniently maintain a set of records corresponding to the active merchant IPSP system: each set of records may include the network identifier and the required communication protocol stored by the credit broker 10 in the database DB 1. Thus during registration with the SSP, a given online merchant may select a merchant IPSP system to which the online merchant has subscribed, e.g., via a drop down list adjusted by the display component 404 of the trusted intermediary 10; the corresponding transmission data (or links thereto) may then be stored with the merchant records maintained in database DB 1. Thus, if a given online merchant has designated its corresponding merchant IPSP system in the manner just described, the trusted intermediary 10, in response to receiving a payment authorization request from the merchant system, may perform an appropriate lookup from the database and retrieve the network identifier, protocol requirements, etc. of the corresponding merchant IPSP system.

Application Program Interface (API) service adapter

The credit mediation system 10 includes an API service adapter enabling connectivity between the credit mediation system 10 and a messaging infrastructure (messaging infrastructure) of the payment system 1. The adapter is configured to manage fulfillment of requests by the trusted intermediary system 10 for external services, such as payment authorization to a merchant IPSP system 3c, and to expose a set of trusted intermediary system 10 services usable by external functions, such as a merchant IPSP system 3 c.

Transaction specific components and data:

the credit agency system 10 stores transaction data such as payment authorization and settlement managed by the credit agency system 10. In addition, the credit brokering system 10 may store audit data associated with user and online merchant activity and general system activity.

Messaging service

The credit brokerage system 10 is configured with an email agent that composes and sends emails for email address authentication and user activation and purchase order confirmation.

As mentioned above, the credit brokering system 10 is preferably implemented as a web application server, such as J2 EE-compatible application server 401 that manages and provides access to the platform's general business logic, and a web server and J2EE servlet engine 403 that serves as the entry point for external HTTP requests from online merchants and from the user's browser to the credit brokering system 10.

The web server and servlet engine 403 includes a display component that exposes a web services based payment API or API wrapper (API wrapper) to the online merchant system. In addition, the web server and servlet engine 403 includes a display processing component 404 configured to generate and manage a user-oriented interface, for example, when a user selects a payment method in the manner described above.

The J2EE application server 401 manages the overall business logic of the network platform and applications. The business logic includes functional software components 411a.. 411e that can be implemented as, for example, a session EJB (enterprise Java Bean). These groups of functions include, for example, an email processing module, an address verification module, and a fraud and security services module; in addition, server 401 includes EJB 3.0 specified by Java object 411f.. 411h that is implemented to, for example, provide access to static and persistent data stored in DB1, such as user data, audit data, and transaction data described above. The credit broker system 10 comprises a web service in the form of an encapsulation that exposes the session EJB to other elements of the payment system 1. More specifically, the functional software components 411a.. 411e interoperate with external service enablers (enablers) 405 such as, among other things, an address verification service 415a, an email application (including access to email servers) 415b, a 3-D security service 415c, an account update service 415D, and a fraud service 415 e. The application server 401 components 411a.. 411e communicate with the application components 415a.. 415e via a set of APIs (the involvement component 413a.. 413e is generally referred to as such). When implemented as a web server, data is transferred between the elements of the payment system 1 (i.e. the elements shown in figures 2 and 3) and the credit mediation system 10 using a secure mechanism, for example via HTTP (multiple HTTP) over a secure socket layer protocol.

In the case of the 3-D security services functionality component 411c, the component invokes the rule using or in cooperation with the risk-based rule to determine whether the component is included in the interaction between the user and the credit broker 10. The rules are typically configured under the control of the fraud service 415e and may, for example, specify when a user registers a payment instrument with the SSP service; a first transaction made to a buyer; for transactions that exceed a certain value; for transactions involving the transportation of goods outside the purchaser's home; and that 3-D security methods should be invoked for certain types of goods and/or services (thereby ensuring that the user is a legitimate cardholder). Other events that may trigger the 3-D security service, including invoking the service for all transactions, will be apparent to those skilled in the art.

Turning to the Account Update (AU) functionality 411d and corresponding services 415d provided by the card planning system 7, the AU component 411d includes routines for routinely viewing the expiration dates of the payment instruments stored in the respective user wallets in the database DB1 and submitting a request to the card planning system 7 with user details that the user's payment instrument is expected to expire within a specified time window. AU component 411d then accesses account update service 415d and collects the response files generated thereby and updates the payment instrument in the relevant user wallet based on the content of the response file.

The processing steps described above with reference to fig. 3, and in particular the steps performed by the credit broker system 10 in particular when interfacing with various payment entities, will now be described in more detail. Turning to fig. 5, at step S5.1, the user selects SSP payment service as the payment method and submits its selection to the online merchant web site. This triggers a request from the online merchant system, in particular a retrieval by the online merchant system of a URL corresponding to the sign-in page of the credit broker system 10, followed by a transmission of the key order (key order) including the returned URL plus the online merchant field (step S5.3), and the creation of a secure session. Upon receiving the login URL from the credit broker system 10, the online merchant system displays a login page to the user (step S5.5). In one arrangement, the sign-in page is implemented as an iFrame that enables the user to communicate directly with the credit brokerage system 10 while remaining within the online environment of the online merchant. The user enters his login details (step S5.7) and is authenticated according to one of the authentication mechanisms described above (step S5.9); if the authentication is successful, the web server and servlet engine 403 sends the data content from the user' S remote storage to the iFrame for display and selection therein (step S5.11). Once the user has selected the user' S payment method from the options within the downloaded remote memory content, the user submits his selected option (step S5.13) to the web server and servlet engine 403 causing a confirmation page to be transmitted to the iFrame (step S5.15).

Once the user confirms the payment selection and submits it (step S5.17), the web server and servlet engine 403 sends the payment details to the online merchant IPSP system 3c via the payment authorisation service (step S5.19), and the trusted intermediary system 10 makes payment on behalf of the online merchant through the payment authorisation service. In some circumstances, the application server 401 invokes the 3-D security process in response to receiving the payment selection at step S5.17. For example, the application server 401 may invoke the 3-D security component 411c that determines whether the user is authenticated through the corresponding issuing bank before transaction processing continues based on the content of the payment request message. In the event that the 3-D security component 411c determines that the transaction has a predetermined level of risk (based on rules accessible by the component 411 c), the 3-D security component 411c configures secure communications between the user and the corresponding 3-D secure issuing bank authentication system 415 c. For example, using a transaction verified by Visa/SecureCode will initiate a redirect to the issuing bank website, or will initiate a load inline frame (inline frame) utterance, authorizing the transaction.

Assuming that the user is authenticated, or in the case that the transaction in question is deemed not to require authentication, step S5.19 involves creating an authorization request received by the payment API 406, converting the payment authorization request into the API format of the online merchant API, and transmitting the formatted request to the merchant IPSP system 3 c. The settlement request is also transmitted to the payment API 406 which performs an API format that translates the settlement request into an API for the online merchant and transmits the formatted request to the merchant IPSP system 3 c. It is recognized that communication may be effectuated by single or dual message implementations. These formatting and transmission activities are recorded in a transaction data store maintained by the credit brokerage system 10 corresponding to the online merchant system.

Once the payment request authorization is notified (step S5.21), the web server and servlet engine 403 transmits the return online merchant URL to the iFrame (step S5.23) along with a notification of successful authorization, causing the iFrame to empty, reload the Javascript code from the online merchant system (step S5.25), and thus remove the iFrame and return the user to the website of the online merchant system. Finally, at step S5.27, the website of the online merchant system displays the successful order placement web page.

In parallel with steps S5.13-S5.19, the application server 401 may record the user' S activity and send the user activity to the audit data store while sending the corresponding system and event information to the third party fraud notification system (this is represented by one of the common service enablers 415e shown in fig. 4). The fraud notification system includes, but is not limited to, a fraud risk engine that performs fraud risk analysis to generate a risk score and recommend an operational mode for the transaction; suitable fraud notification systems, such as by RSA^TMFraud notification systems, provided in their fraud prevention kits, are known and will not be described in detail herein. The risk scores and the manner of operation are stored in the database DB1 along with other transaction details for online merchants and users.

The above embodiments are to be understood as illustrative examples of the invention. Other embodiments of the invention are contemplated. For example, although the trusted intermediary system 10 is described in the foregoing example as receiving payment requests from an online merchant system, in the event that such a merchant IPSP system has been modified to provide an SSP as a payment option, the intermediary 10 may additionally or alternatively receive payment requests from the merchant IPSP system in the third type of arrangement described in the background section.

Further, while the preferred embodiment utilizes iFrame network technology to navigate the user to a different website, it should be recognized that standard network redirection may be employed instead. In this alternative arrangement, the user's browser is navigated away and back to the SSP website, depending on the entity with which the user's browser communicates at any point in time (specifically the URL corresponding thereto). For example, during authentication and/or account selection by the user, the user browser may be redirected by the SSP website to a website provided by or on behalf of the user's issuing bank, and once user authentication and/or account selection is complete, the user browser may be redirected by the issuing bank website back to the SSP website.

In the foregoing embodiment, the credit brokering system 10 is described as storing the shipping details in a set of user records: to some extent, the credit brokerage system 10 may be considered part of providing the functionality associated with a checkout instrument: the relevant fields stored in database DB1 are accessible through an interface, enabling the merchant system to reference this data during the checkout process and to adapt the combined fields. However, it is to be understood that this is an optional aspect of the intermediary 10. In practice, the online merchant system 1c may provide checkout functionality, in which case the credit brokering system 10 will only effect the role of a payment instrument, and then the database DB1 stores fewer user-specified information entries.

In the foregoing description, the term "system" when applied to entities such as merchant systems, merchant IPSP systems, trusted intermediary systems and other entities should be understood to mean data processing functions provided at one or more physical sites connected to other data processing functions via data communications links. Each function may be provided by a single data processing node (e.g., a server computer), or a group of data processing nodes (such as a group of computers) that provide fail-over backups to each other, and/or a group of interconnected data processing nodes (e.g., a group of inter-working different server computers) that provide different component sub-functions with respect to the group of other components.

As will be appreciated from the foregoing, communication between the various entities comprising the payment system 1 is preferably via a data communication network such as the internet. Each entity of the payment system 1 (issuing bank; credit broker; acquiring bank processor; merchant IPSP system; and online merchant system) is identified via a network identifier such as an Internet Protocol (IP) address or other suitable identifier.

Thus, a communication network may include a network comprising one or more technologies, i.e., a hybrid communication network; for example, the network may comprise the internet with a Public Switched Telephone Network (PSTN) and/or a mobile communications network capable of supporting, for example, one or more of the following communication protocols: GSM (global system for mobile communications), WCDMA (wideband code division multiple access), GPRS (general packet radio service). In addition to or instead of mobile communication networks, local area networks such as Wireless Local Area Networks (WLAN) or(BT) and/or other techniques (such as WiMax) may be used to undertake portions of the payment authorization request and response messages. In this way, the user may interact with the online merchant system using a portable, remote device. The data communications network may be arranged to support general internet access using any delivery method. Additionally or alternatively, to send the confirmation message as an email message, the payment confirmation message may be converted into an SMS message (short message service), an MMS message (multimedia service), a Wireless Application Protocol (WAP) page, an internet page, an HTML (hypertext markup language) page, an XHTML (extended HTML) page, or an IP datagram (internet protocol).

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims (22)

1. A method of processing a payment authorisation request for a payment transaction conducted via a data communications network on behalf of an online merchant, the payment authorisation request being executed as a result of orders placed by a financial instrument holder via a plurality of different online merchant systems, each of the online merchants having an online merchant identity and each of the online merchants being associated with one of a plurality of acquiring banks,

wherein the method is performed by a credit broker system arranged to transmit a payment authorisation request to each of a plurality of online merchant internet payment service provider systems,

each of the merchant internet payment service provider systems is arranged to transmit a payment authorisation request to at least one of a plurality of acquiring bank payment processor systems, each of the plurality of acquiring bank payment processor systems being responsible for processing payment authorisations for at least one of the acquiring banks, and

the credit broker system comprising a database configured to store merchant internet payment service provider system transmission data enabling transmission of payment authorisation request data to selected merchant internet payment service provider systems, and merchant profile data comprising, for each of the online merchants, an online merchant identity and an identifier of the merchant internet payment service provider system with which the online merchant is registered,

the method comprises the following steps:

receiving a payment authorization request involving authorization of a payment transaction from a first online merchant system responsible for initiating a payment authorization request for a first online merchant, the received payment authorization request initiated as a result of an order placed by a financial instrument holder via the first online merchant system, the received payment authorization request including an online merchant identity associated with the first online merchant;

in response to receiving the request:

a) generating a payment authorization request containing transaction data, the transaction data comprising:

i) a financial instrument identity to be used by the financial instrument holder in a payment transaction; and

ii) an online merchant identity associated with the first online merchant as the payment transaction payee; and

iii) one or more transaction details including the payment amount; and

b) selecting the merchant internet payment service provider system with which the first online merchant is registered by performing a lookup in the database using an online merchant identity associated with the first online merchant;

c) retrieving transmission data associated with the selected merchant internet payment service provider system; and

d) converting the payment authorization request to an Application Program Interface (API) format of the online merchant based on the retrieved merchant Internet payment service provider system transmission data, and transmitting the payment authorization request having the format to the selected merchant Internet payment service provider system, generating and transmitting additional payment authorization requests from the selected merchant Internet payment service provider system to an acquiring bank payment processor system responsible for processing payment authorization for the acquiring bank associated with the first online merchant.

2. The method as recited in claim 1, wherein the credit broker system receives a payment authorization response from the selected merchant internet payment service provider system and transmits a payment authorization response to the first online merchant system in response thereto.

3. The method of claim 1 or 2, wherein the online merchant identity included in the generated authorization request is generated based on the received online merchant identity.

4. The method of any one of claims 1 to 2, wherein the step of retrieving the merchant internet payment service provider system transmission data comprises retrieving a network address of the selected merchant internet payment service provider system, and the step of transmitting the generated payment authorization request to the selected merchant internet payment service provider system comprises transmitting the generated payment authorization request based on the retrieved network address.

5. The method of any of claims 1-2, wherein the financial instrument identity comprises a primary account number associated with the financial instrument.

6. The method of claim 5, wherein the primary account number comprises a credit card number or a debit card number.

7. The method of any of claims 1-2, wherein the selected merchant internet payment service provider system provides settlement of payment transactions for an online merchant account on behalf of the first online merchant, the payment transactions being conducted through the online merchant account.

8. The method of any of claims 1-2, wherein the credit broker system provides a registration interface for the first online merchant whereby the first online merchant can register a merchant internet payment service provider system associated with the first online merchant.

9. The method of any of claims 1-2, wherein the credit brokerage system receives and processes payment authorization requests for a first type of payment transaction initiated from the first online merchant system and transmits the generated payment authorization request to the selected merchant internet payment service provider system in response, and wherein the selected merchant internet payment service provider system receives and processes payment authorization requests for a different type of payment transaction initiated from the first online merchant system than the first type of payment transaction, the payment authorization requests for the different type of payment transaction not being processed by the brokerage system.

10. The method of claim 9, wherein the payment authorization request for a first type of payment transaction initiated from the first online merchant system does not include the financial instrument identity, and the payment authorization request for the different type of payment transaction initiated from the first online merchant system includes a financial instrument identity collected by the online merchant system during order processing for the different type of payment transaction.

11. The method of claim 10, wherein the financial instrument identity collected by the online merchant system during order processing for the different types of payment transactions comprises a credit card number or a debit card number.

12. A payment authorisation system for processing on behalf of an online merchant a payment authorisation request for a payment transaction conducted via a data communications network, the payment authorisation request being executed as a result of orders placed by a financial instrument holder via a plurality of different online merchant systems, each of said online merchants having an online merchant identity and each of said online merchants being associated with one of a plurality of different acquiring banks,

wherein the payment authorization system comprises a credit broker system arranged to communicate with a plurality of different online merchant internet payment service provider systems and with a plurality of the online merchants, the credit broker system being arranged to transmit payment authorization requests to each of the plurality of different online merchant internet payment service provider systems,

wherein each of the merchant internet payment service provider systems is arranged to transmit a payment authorisation request to at least one of a plurality of acquiring bank payment processor systems, each of the plurality of acquiring bank payment processor systems being responsible for processing payment authorisations for at least one of the acquiring banks,

wherein the credit broker system comprises a database configured to store merchant internet payment service provider system transmission data enabling transmission of payment authorisation request data to a selected merchant internet payment service provider system, and merchant profile data comprising for each of the online merchants an online merchant identity and an identifier of the merchant internet payment service provider system with which the online merchant system is registered,

wherein, in response to a payment authorization request relating to authorization of a payment transaction from a first online merchant system, the payment authorization request being initiated as a result of an order placed by a financial instrument holder via the first online merchant system, and the first online merchant system is responsible for initiating a payment authorization request for the first online merchant, and the received payment authorization request includes an online merchant identity associated with the first online merchant,

the credit mediation system is configured to:

a) generating a payment authorization request containing transaction data, the transaction data comprising:

i) a financial instrument identity to be used by the financial instrument holder in a payment transaction; and

ii) an online merchant identity associated with the first online merchant as the payment transaction payee; and

iii) one or more transaction details including the payment amount; and

b) selecting the merchant internet payment service provider system with which the first online merchant is registered by performing a lookup in the database using an online merchant identity associated with the first online merchant;

c) retrieving transmission data associated with the selected merchant internet payment service provider system; and

d) based on the retrieved merchant internet payment service provider system transmission data, converting the payment authorization request to an Application Program Interface (API) format of the online merchant and transmitting the payment authorization request having the format to the selected merchant internet payment service provider system, additional payment authorization requests may be generated from the selected merchant internet payment service provider system and transmitted to an acquiring bank payment processor system responsible for processing payment authorization for the acquiring bank associated with the first online merchant.

13. The payment authorization system according to claim 12, wherein the credit broker system is configured to receive a payment authorization response from the selected merchant internet payment service provider system and transmit a payment authorization response to the first online merchant system in response thereto.

14. The payment authorisation system of claim 12 or 13, wherein the credit broker system is configured to generate the online merchant identity for inclusion in the generated authorisation request based on the received online merchant identity.

15. The payment authorisation system of any one of claims 12 to 13, wherein the credit broker system is configured to:

retrieving the network address of the selected merchant internet payment service provider system, thereby retrieving the merchant internet payment service provider system transmission data; and

transmitting the generated payment authorization request based on the retrieved network address, thereby transmitting the generated payment authorization request to the selected merchant internet payment service provider system.

16. The payment authorisation system of any one of claims 12 to 13, wherein the financial instrument identity comprises a primary account number associated with the financial instrument.

17. The payment authorization system of claim 16, wherein the primary account number comprises a credit card number or a debit card number.

18. The payment authorization system according to any one of claims 12 to 13, wherein the selected merchant internet payment service provider system provides settlement of payment transactions for an online merchant account on behalf of the first online merchant, the payment transactions being conducted through the online merchant account.

19. The payment authorization system according to any one of claims 12 to 13, wherein the credit broker system is configured to provide a registration interface for the first online merchant whereby the first online merchant can register a merchant internet payment service provider system associated with the first online merchant.

20. The payment authorization system according to any one of claims 12 to 13, wherein the credit broker system is configured to receive and process payment authorization requests for a first type of payment transaction initiated from the first online merchant system and in response transmit the generated payment authorization request to a selected merchant internet payment service provider system, and wherein the selected merchant internet payment service provider system receives and processes payment authorization requests for a different type of payment transaction initiated from the first online merchant system than the first type of payment transaction, the payment authorization requests for the different type of payment transaction not being processed by the broker system.

21. The payment authorization system according to claim 20, wherein the payment authorization request for a first type of payment transaction initiated from the first online merchant system does not include the financial instrument identity, and the payment authorization request for the different type of payment transaction initiated from the first online merchant system includes a financial instrument identity collected by the online merchant system during order processing for the different type of payment transaction.

22. The payment authorization system of claim 21, wherein the financial instrument identity collected by the online merchant system during order processing for the different types of payment transactions comprises a credit card number or a debit card number.