MX2011007256A

Payment system.

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.

Term

3.3 yearsleft in the term

Expires 6 January 2030.

26 claims: 12 independent, 14 dependent

1
REIVINDICACIONES pago se conducen como un resultado de pedidos por titulares de instrumentos financieros vía una pluralidad de diferentes sistemas comerciales en línea, cada uno de los comercios en 10 línea tiene una identidad de comercio en línea, y cada uno de los comercios en línea se asocia con uno de una pluralidad de bancos adquisidores, en donde el método se conduce por un sistema intermediario central confiable el cual se arregla para 15 transmitir solicitudes de autorización de pago a cada uno de una pluralidad de sistemas Proveedores de Servicio de Pago por Internet (IPSP) comerciales en linea, cada uno de los sistemas IPSP comerciales se arregla para transmitir solicitudes de autorización de pago a
2
2 0 al menos uno de una pluralidad de sistemas procesadores de pago de banco adquisidor, cada uno de la pluralidad de sistemas procesadores de pago de banco adquisidor es responsable de procesar autorizaciones de pago para al menos uno de los bancos adquisidores, y 25 caracterizado porque el método comprende:recibir desde un primer sistema comercial en línea, responsable de originar solicitudes de autorización de pago para un primer comercio en línea, una solicitud de autorización de pago relacionada con la autorización de una transacción de pago, la solicitud de autorización de pago recibida se inicia como un resultado de un titular de instrumentos financieros que conduce un pedido vía el primer sistema comercial en línea;en respuesta a la recepción de la solicitud: a) generar una solicitud de autorización de pago que comprende datos de transacción que incluyen: i) una identidad de instrumento financiero que se usa en la transacción de pago por el titular de instrumentos financieros;y ii) una identidad de comercio en línea, asociada con el primer comercio en línea, como el beneficiario de la transacción de pago;y iii) uno o más detalles de la transacción incluyendo una cantidad del pago;y b) recuperar los datos de transmisión para habilitar la transmisión de datos de solicitud de autorización de pago a un sistema IPSP comercial seleccionado asociado con el primer comercio en línea;y c) sobre la base de los datos de transmisión recuperados, transmitir la solicitud de autorización de pago generada al sistema IPSP comercial seleccionado, de donde una solicitud de autorización de pago adicional se puede generar y transmitir a un sistema procesador de pago de banco adquisidor responsable de procesar las autorizaciones de pago para el banco adquisidor con el cual el primer comercio en línea se asocia. 2. Un método de conformidad con la reivindicación 1, caracterizado porque el sistema intermediario central confiable recibe una respuesta de autorización de pago del sistema IPSP comercial seleccionado, y en respuesta a esto transmite una respuesta de autorización de pago al primer sistema comercial en línea.
3
Un método de conformidad con la reivindicación 1 o reivindicación 2, caracterizado porque el primer comercio en línea es un titular de cuenta de comercio en línea con el banco adquisidor con el cual se asocia.
4
Un método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el método comprende recibir una identidad de comercio en línea del primer sistema comercial en línea, la identidad de comercio en línea incluida en la solicitud de autorización generada se genera sobre la base de la identidad de comercio en línea recibida.
5
Un método de conformidad con la reivindicación 1, caracterizado porque al menos algunos de la pluralidad de sistemas IPSP comerciales transmiten solicitudes de autorización de pago a más de uno de la pluralidad de sistemas procesadores de pago de banco adquisidor.
6
Un método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el método comprende recibir datos que indican una selección, por el titular de instrumentos financieros, entre una pluralidad de diferentes instrumentos financieros para uso en la transacción de pago, y recuperar una identidad de instrumento financiero que se usa en la solicitud de autorización de pago generada sobre la base de la selección indicada.
7
Un método de conformidad con cualquiera de las reivindicaciones precedentes, en donde el sistema intermediario central confiable proporciona una interfaz de registro para un titular de instrumentos financieros por lo cual el titular de instrumentos financieros puede proporcionar una identidad de instrumento financiero para el registro con el sistema intermediario central confiable como datos de registro almacenados, caracterizado porque el método comprende la etapa de autenticar un titular de instrumentos financieros y, en respuesta a esto, recuperar una identidad de instrumento financiero registrada que se usa en la solicitud de autorización de pago generada de los datos de registro almacenados.
8
Un método de conformidad con la reivindicación 1, caracterizado porque la etapa de recuperar datos de transmisión comprende recuperar una dirección de red para el sistema IPSP comercial seleccionado, y la etapa de transmitir la solicitud de autorización de pago generada al sistema IPSP comercial seleccionado comprende transmitir la solicitud de autorización de pago generada sobre la base de la dirección de red recuperada.
9
Un método de conformidad con cualquiera de las reivindicaciones precedentes, en donde el sistema intermediario central confiable coopera con una pluralidad de sistemas de autenticación emisores, cada uno es responsable de conducir la autenticación para un diferente banco emisor, caracterizado porque el método comprende la etapa de comunicarse selectivamente con un sistema de autenticación emisor respectivo para verificar la identidad del titular de instrumentos financieros.
10
Un método de conformidad con la reivindicación 9, caracterizado porque comprende transmitir datos al titular de instrumentos financieros para realizar la autenticación con respecto al sistema de autenticación emisor, y recibir datos de respuesta de verificación del sistema de autenticación emisor en respuesta a la verificación del titular de instrumentos financieros por el banco emisor correspondiente.
11
Un método de conformidad con la reivindicación 9 o reivindicación 10, caracterizado porque la verificación del titular de instrumentos financieros se realiza de conformidad con el protocolo de mensajería 3-D Secure.
12
Un método de conformidad con cualquiera de las reivindicaciones precedentes, en donde el sistema intermediario central confiable coopera con una pluralidad de sistemas de autenticación emisores, cada uno es responsable de conducir la autenticación para un diferente banco emisor, caracterizado porque el método comprende la etapa de recuperar una identidad de instrumento financiero que se usa en la solicitud de autorización de pago generada sobre la base de la autenticación del titular del instrumento por uno de la pluralidad de sistemas de autenticación emisores seleccionados.
13
Un método de conformidad con la reivindicación 12, caracterizado porque comprende transmitir datos al titular de instrumentos financieros habilitando al titular de instrumentos financieros para realizar la autenticación con respecto a un sistema de autenticación seleccionado, y recibir datos de respuesta de autenticación del sistema de autenticación seleccionado en respuesta a la autenticación del titular de instrumentos financieros por el sistema de autenticación emisor seleccionado.
14
Un método de conformidad con la reivindicación 12 o reivindicación 13, caracterizado porque comprende recibir datos que indican una identidad de instrumento financiero que se usa en la solicitud de autorización de pago generada del sistema de autenticación emisor seleccionado en respuesta a la autenticación del titular de instrumentos financieros por el sistema de autenticación emisor seleccionado.
15
Un método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque la identidad de instrumento financiero comprende un Número de Cuenta Principal (PAN) asociado con el instrumento financiero.
16
Un método de conformidad con la reivindicación 15, caracterizado porque el PAN comprende un número de tarjeta de crédito o número de tarjeta de débito.
17
Un método de conformidad con la reivindicación 1, caracterizado porque el sistema IPSP comercial proporciona liquidación de la transacción de pago para una cuenta de comercio en línea a través de la cual la transacción de pago se conduce, en beneficio del primer comercio en línea.
18
Un método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el sistema IPSP comercial proporciona historial de transacción de pago para el primer comercio en linea, el historial de transacción de pago es accesible por el primer comercio en línea vía una interfaz de comercio en línea proporcionada por el IPSP comercial.
19
Un método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el sistema intermediario central confiable proporciona una interfaz de registro para el primer comercio en línea por lo cual el primer comercio en línea puede registrar un sistema IPSP comercial con el cual el primer comercio en línea se asocia, y en donde la etapa de recuperar datos de transmisión para habilitar la transmisión de datos de solicitud de autorización de pago al sistema IPSP comercial seleccionado asociado con el primer comercio en línea se conduce sobre la base del sistema IPSP comercial registrado por el primer comercio en línea.
20
Un método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el sistema intermediario central confiable recibe y procesa solicitudes de autorización de pago para transacciones de pago de un primer tipo originadas del primer sistema comercial en línea, y en respuesta a esto transmitir una solicitud de autorización de pago generada al sistema IPSP comercial seleccionado, y en donde los sistemas IPSP comerciales reciben y procesan solicitudes de autorización de pago para transacciones de pago de un tipo diferente originadas del primer sistema comercial en línea, las solicitudes de autorización de pago para transacciones de pago de un diferente tipo no se procesan vía el sistema intermediario central..
21
Un método de conformidad con la reivindicación 20, caracterizado porque las solicitudes de autorización de pago para transacciones de pago de un primer tipo originadas del primer sistema comercial en línea no incluyen la identidad de instrumento financiero y las solicitudes de autorización de pago para transacciones de pago del tipo diferente originadas del primer sistema comercial en línea incluyen una identidad de instrumento financiero colectada por el sistema comercial en línea durante el procesamiento de transacciones de pago de diferente tipo.
22
Un método de conformidad con la reivindicación 21, caracterizado porque la identidad de instrumento financiero colectada por el sistema comercial en línea durante el procesamiento de transacciones de pago de diferente tipo comprende un número de tarjeta de crédito o un número de tarjeta de débito.
23
Un sistema intermediario confiable en comunicación con una pluralidad de sistemas comerciales en línea y una pluralidad de sistemas IPSP comerciales, caracterizado porque el sistema intermediario confiable se arregla para conducir las etapas de sistema intermediario confiable de un método de conformidad con cualquiera de la reivindicación 1 a reivindicación 22.
24
Un sistema comercial en línea en comunicación con un sistema intermediario confiable y una pluralidad de sistemas IPSP comerciales, caracterizado porque el sistema comercial en línea se arregla para conducir las etapas de sistema comercial en línea de un método de conformidad con cualquiera de la reivindicación 1 a reivindicación 22.
25
Un sistema IPSP comercial en comunicación con un sistema intermediario confiable y una pluralidad de sistemas comerciales en línea, caracterizado porque el sistema IPSP comercial se arregla para conducir las etapas de sistema IPSP comercial de un método de conformidad con cualquiera de la reivindicación 1 a reivindicación 22.
26
Un sistema de autorización de pago para el procesamiento de solicitudes de autorización de pago con respecto a las transacciones de pago que se conducen vía una red de comunicaciones de datos en beneficio de comercios en línea, las solicitudes de autorización de pago se conducen como un resultado de pedidos por titulares de instrumentos financieros vía una pluralidad de diferentes sistemas comerciales en línea, cada uno de los comercios en línea tiene una identidad de comercio en línea, caracterizado porque el sistema de autorización de pago comprende un sistema intermediario central confiable arreglado para comunicarse con una pluralidad de diferentes sistemas Proveedores de Servicio de Pago por Internet (IPSP) comerciales en línea y con una pluralidad de comercios en línea, el sistema intermediario central confiable se arregla para transmitir solicitudes de autorización de pago a cada uno de la pluralidad de diferentes sistemas Proveedores de Servicio de Pago por Internet (IPSP) comerciales en línea, cada uno de los sistemas IPSP comerciales se arregla para transmitir solicitudes de autorización de pago a al menos uno de una pluralidad de sistemas procesadores de pago de banco adquisidor, cada uno de la pluralidad de sistemas procesadores de pago de banco adquisidor es responsable de procesar autorizaciones de pago para al menos uno de los bancos adquisidores, en donde, en respuesta a una solicitud de autorización de pago relacionada con la autorización de una transacción de pago de un primer sistema comercial en línea, la solicitud de autorización de pago recibida se inicia como un resultado de un titular de instrumentos financieros que conduce un pedido vía el primer sistema comercial en línea y el sistema comercial en línea es responsables de originar solicitudes de autorización de pago para el primer comercio en línea, el sistema intermediario confiable se arregla para:a) generar una solicitud de autorización de pago que comprende datos de transacción que incluyen: i) una identidad de instrumento financiero que se usa en la transacción de pago por el titular de instrumentos financieros;y ii, una identidad de comercio en línea, asociada con el primer comercio en línea, como el beneficiario de la transacción de pago;y iii) uno o más detalles de la transacción incluyendo una cantidad del pago;y b) recuperar los datos de transmisión para habilitar la transmisión de datos de solicitud de autorización de pago a un sistema IPSP comercial seleccionado asociado con el primer comercio en línea;y c) sobre la base de los datos de transmisión recuperados, transmitir la solicitud de autorización de pago generada al sistema IPSP comercial seleccionado, de donde una solicitud de autorización de pago adicional se puede generar y transmitir a un sistema procesador de pago de banco adquisidor responsable de procesar las autorizaciones de pago para el banco adquisidor con el cual el primer comercio en línea se asocia.

Independent claims26

143 paragraphs in 3 sections, as filed

(54) Title: PAYMENT SYSTEM.

(57) Summary

The embodiments of the invention provide a method of processing payment authorization requests for payment transactions that are conducted via a data communications network for the benefit of online merchants, payment authorization requests are conducted as a result of orders By holders of financial instruments via a plurality of different online trading systems, each of the online merchants has an online trading identity. The method is driven by a trusted central intermediary system which is arranged to transmit payment authorization requests to each of a plurality of online commercial Internet Payment Service Provider (IPSP) systems; Each commercial IPSP system is arranged to transmit payment authorization requests to at least one of a plurality of acquiring bank payment processing systems, and each of the plurality of acquiring bank payment processing systems is responsible for processing payment authorizations. for at least one of the acquiring banks. The method comprises: receiving from a first online trading system, responsible for originating payment authorization requests for a first online business, a payment authorization request related to the authorization of a payment transaction, the payment authorization request Received starts as a result of a financial instrument holder conducting an order via the first online trading system; in response to receipt of the request: a) generate a payment authorization request comprising transaction data including: i) a financial instrument identity that is used in the payment transaction by the holder of financial instruments; and ii) an online business identity, associated with the first online business, as the beneficiary of the payment transaction; and iii) one or more details of the transaction including a payment amount; and b) retrieve transmission data to enable transmission of payment authorization request data to a selected business IPSP system associated with the first online business; and based on the retrieved transmission data, transmit the generated payment authorization request to the selected commercial IPSP system, from where an additional payment authorization request can be generated and transmitted to an acquiring bank payment processing system responsible for process payment authorizations for the acquiring bank with which the first online business is associated. The embodiments of the invention enable a user to select a payment method on a per transaction basis, while removing the requirement that the user provide payment details to individual online business systems or their business IPSP systems. Accordingly, as long as online merchants, or their commercial 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.

(57) Abstract

Embodiments of the invention provide a method of Processing payment authorization requests for payment transactions to be conducted via a data Communications network on behalf of online merchants, the payment authorization 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 authorization 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 authorization 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 authorizations for at least one of said acquiring banks . The method comprises: receiving from a first online merchant system, responsible for originating payment authorization requests for a first online merchant, a payment authorization request relating to authorization of a payment transaction, said received payment authorization 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 authorization 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 authorization 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 authorization request to the selected merchant IPSP system, wherefrom a further payment authorization request may be generated and transmitted to an acquiring bank payment processor system responsible for processing payment authorizations 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.

PAYMENT SYSTEM

FIELD OF THE INVENTION

The present invention relates to a system and method of processing payment authorization requests for payment transactions that are conducted via a data communications network for the benefit of online merchants, and is particularly, but not exclusively, suitable for processing of orders made by holders of financial instruments.

BACKGROUND OF THE INVENTION

Users are increasingly encouraged to buy merchandise online, that is, via the Internet and associated technologies. Generally speaking, existing online payment systems fall into one of three types of arrangements: In a first type of arrangement, an online trading system collects the payment details of a financial instrument holder, otherwise known as a buyer or cardholder, without the buyer dealing directly with any other entity that may be involved in the transaction, and the online trading system sends the transaction details directly to your acquiring bank system. In a second type of arrangement, the online trading system collects a buyer's payment details without the buyer directly dealing with some other identity that may be involved in the transaction, and the online trading system sends the details of the transaction. to a Service Provider

Online Commercial Internet Payments (IPSP) which processes payment authorizations for the benefit of the merchant. The commercial IPSP system then transmits the details to the online merchant acquiring bank system; details can be transmitted directly to the acquiring bank or to a payment processor which acts on behalf of the acquiring bank. Examples of systems

IPSPs which provide support for this second type of arrangement include the Protx ™ Veri-Secure (VSP) Payment system.

In an arrangement of the first and second types, the online trading system typically obtains payment card data, bank account information, and / or other financial data from the buyer. The online trading system then passes this information either directly, or via the commercial IPSP system, to a processing system of the acquiring bank. Each online trading system is assigned an online trading account identifier by an acquiring bank, and this account identifier is used to identify online trading for the acquiring bank when requesting authorization for a transaction.

Figure 1 shows an example of conventional online payment systems according to arrangements of the second type, comprising a plurality of online commercial systems la, lb, le. In this arrangement each of the online merchants is an operational partnership with an online commercial Internet Payment Service Provider (IPSP) 3 system, which is a selected payment gateway subscribed to by the online merchant for the purposes of conducting safe business on the Internet. While the figure shows each of the online trading systems the ... being associated with the same commercial IPSP 3 system, alternatively, and in fact frequently in practice, online commercial systems are linked to different commercial IPSP systems

3. Each commercial IPSP 3 system provides a system that passes payment card data, authorization requests, and authorization responses over the Internet using encryption technology. The transaction information is sent by the commercial IPSP system 3, via a data communications link, to the acquiring bank 5, and therefore to the card scheme system 7 which intermediates with an issuing bank where the validity of the Card is checked and the availability of funds in this account is verified. An authorization code is returned to the commercial IPSP system 3; authorization is encrypted by the system

Commercial IPSP 3 and it is transmitted in encrypted form to the online commercial system la, which activates the fulfillment of the order.

A conventional end-to-end online transaction using an arrangement of the second type and involving the entities shown in Figure 1 comprises the following steps:

* A website of the online trading system collects from a buyer one or more order picks. The buyer pays, enters their payment details and places an order on the website of the online merchant system 1 by pressing the 'Deliver Order' button or equivalent on the order transmission web page of the merchant website.

* The buyer's web browser encrypts the information to be sent between the search engine and the online commerce web server.

* Online commerce then transmits the details of the transaction to your commercial IPSP 3 system, typically via another encrypted connection to the payment server hosted by the commercial IPSP 3 system.

* The commercial IPSP 3 system transmits the transaction information, including the internet account identifier of the online business, to the processor used by the online business acquiring bank system 5.

* Processor 5 transmits the transaction information to the payment scheme system 7 (eg Visa / MasterCard).

* The payment scheme system 7 routes the transaction to the correct system of the card issuing bank 9.

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

* Online merchant acquiring bank system processor 5 transmits the response to the system

Commercial IPSP 3.

* The commercial IPSP 3 system receives the response, and transmits it to the online commerce system where it is interpreted and a relevant response is then retransmitted, via the commerce to the buyer confirming that the transaction has been authorized.

* The commercial IPSP 3 system, for the benefit of online commerce, submits all its approved authorizations to the online merchant acquiring bank system 5 for settlement.

* The acquiring bank system 5 deposits the total of the approved funds minus any fees and charges into the assigned online trading account. This could be an account with the acquiring bank if the online business does its banking with the same bank, or an account with another bank.

An advantage of using a payment gateway such as the commercial IPSP system shown in Figure 1 is that the commercial IPSP system can provide one or more other additional transaction processing functions, eg settlement, chargeback handling, handling of refunds, and reporting of transactions, for the benefit of online commerce. In the settlement procedure, the commercial IPSP 3 system submits all approved online trade authorizations collected during a given period, in one batch, to the online merchant acquiring bank system 5 for settlement. A chargeback is a revocation of a payment card transaction initiated by the buyer or the bank that issued the card used in the purchase. This differs from a refund, which is agreed and initiated by online commerce, via the commercial IPSP system 3. Transaction reporting involves providing a summary reporting function for cumulative transactions which have been authorized and optionally settled via the commercial IPSP 3 system, so that a merchant, for example, can select a date range and view a related summary with all transactions conducted within the selected data range. A commercial IPSP 3 system can provide an online merchant with a secure online website to approve chargebacks, initiate refunds, and / or view transaction reports as described.

However, in each of the first and second types of payment systems described above, a buyer is required to provide their payment information.

<td>separately</td><td>of</td><td>the</td><td>transactions</td><td>started with</td><td>every</td>

<td colspan="2">different trade</td><td>in</td><td colspan="2">line. Therefore, for</td><td>every</td>

<td>new trade</td><td>in</td><td>line</td><td>with which a</td><td colspan="2">buyer interacts,</td>

<td>increases the</td><td colspan="3">exposure risk,</td><td>embezzlement and / or</td><td>use</td>

<td>fraudulent</td><td>the</td><td>data</td><td>financial</td><td>buyer.</td><td></td>

In a third type of arrangement (not shown) the online trading system redirects the buyer to an alternative payment system website with which the buyer interacts to complete the transaction. The alternative payment system interacts directly with the user who provides the payment to the alternative payment system either directly from their bank account or via a mechanism such as a payment card. Where a payment card from a conventional payment scheme is used, the alternative payment system plays the role of the merchant in the conventional payment system, submitting a payment request through an acquiring system. The payment of the user is made to the alternative payment system. The alternative payment system is then responsible for any refund from the merchant.

In a second case, the alternative payment system can, in effect, behave like a conventional clearing house, financing a user account within the alternative payment system of the user's current issuing bank account by charging a sum directly to their account. . The alternative payment system subsequently ensures that the payment is sent to the merchant's issuing bank account, usually through a conventional clearing house. This merchant bank account may or may not be the same as your account held with your conventional purchasing system. Accordingly, most third-party deferred payment systems act as the intermediary to take the user's current funds and transfer them to the merchant, most usually via the individual consumer and merchant bank accounts, potentially withholding those funds when they go to through accounts maintained by the payment system; An example of this third type of payment system includes the PayPal payment system.<sup>(TM></sup> well known. Such a payment system may also have the ability to operate like a conventional IPSP, for example by providing associated online payment management services.

While this type of payment system alleviates the user's need to establish individual payment accounts on an online merchant basis, the user has a relationship with the alternative payment system and not with the online trading system; This causes several notable disadvantages: first, online commerce does not receive payment directly from an acquiring bank, nor can it avail itself of a payment guarantee based on the payment scheme, since for these transactions there is no direct relationship between the commerce and a card payment scheme. Second, for transactions made via card payment, the buyer does not have visibility of the individual online business from which the product was purchased (instead, the card statement identifies the entity of the alternative payment system). Third, the buyer is not protected by the rules of the card scheme and cannot be protected by any applicable consumer protection, because the transaction is with the payment system, and not with the online trading system.

Brief Description of the Invention

In accordance with at least one embodiment of the invention, the systems and software are provided for the processing of payment authorization requests for payment transactions that are conducted via a data communications re for the benefit of online merchants, as specified. in the independent claims. This is accomplished by a combination of features cited in each independent claim. Accordingly, the dependent claims prescribe additional detailed implementations of the present invention.

More particularly, aspects of the invention provide a method for processing payment authorization requests for payment transactions that are conducted via a data communications network for the benefit of online merchants, payment authorization requests are conducted as a result of orders by holders of financial instruments via a plurality of different online trading systems, each of the online merchants has an online commerce identity, and each of the online merchants is associated with one of a plurality of acquiring banks, where the method is driven by a reliable central intermediary system which is arranged to transmit payment authorization requests to each of a plurality of different online commercial Internet Payment Service Provider (IPSP) systems, each of the commercial IPSP systems is arranged to transmit payment authorization requests to at least one of a plurality of acquiring bank payment processing systems that are responsible for processing payment authorizations for at least one of the acquiring banks, the method understands:

receive from a first online merchant system, responsible for originating payment authorization requests for a first online commerce, a payment authorization request related to the authorization of a payment transaction, the received payment authorization request starts as a result of a financial instrument holder conducting an order via the first online trading system;

in response to receiving the request:

a) generate a payment authorization request that includes transaction data including:

i) a financial instrument identity that is used in the payment transaction by the holder of the financial instrument; and ii) an online business identity, associated with the first online business, as the beneficiary of the payment transaction; and iii) one or more details of the transaction including a payment amount; and

b) retrieve transmission data to enable transmission of payment authorization request data to a selected business IPSP system associated with the first online business; and based on the retrieved transmission data, transmit the generated payment authorization request to the selected commercial IPSP system, from where an additional payment authorization request can be generated and transmitted to an acquiring bank payment processing system responsible for process payment authorizations for the acquiring bank with which the first online business is associated.

Preferably, the method comprises receiving data indicating a selection, by the holder of financial instruments, among a plurality of different financial instruments for use in the payment transaction, and retrieving a financial instrument identity that is used in the application for authorization of payment generated on the basis of the indicated selection. The different financial instruments are advantageously held in a local warehouse, or user portfolio, by the reliable intermediary system. Accordingly, the embodiments of the invention enable a holder of financial instruments, or user, to select a payment method on a per transaction basis, while removing the user requirement to provide payment details to individual online trading systems or their commercial IPSP systems. Accordingly, as long as online merchants, or their commercial 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. This has the benefit of reducing the risk of fraud that may be incurred relative to conventional payment system arrangements, while allowing users to transact more quickly and conveniently because there is no need for the user to enter personal and financial information. regarding each transaction.

As for the population of the user portfolio with payment instrument details, the trusted central intermediary system preferably provides a registration interface for a financial instrument holder whereby the financial instrument holder can provide a financial instrument identity for registration with the trusted central intermediary system as stored registry data. When processing a payment authorization request the method comprises the step of authenticating a financial instrument holder and, in response to this, retrieving a registered financial instrument identity, preferably from the user wallet, which is used in the request for payment authorization generated from the stored registration data.

The terms online commerce, commercial IPSP system, trusted central intermediary system and acquiring bank payment processing system shall be understood to refer to logical components. As such, each system can be included physically separate from each other or physically connected to one or more systems. For example, in arrangements where a given organization hosts the commercial IPSP system and online commerce, the components may be physically located on the same network or even integrated as part of a single system. Furthermore, where a given organization houses the commercial IPSP system and acquiring bank's payment processing system, the components may be physically located on the same network or even integrated as part of a single system. Still further, the organization may host online commerce, the commercial IPSP system and the acquiring bank payment processing system. Accordingly, the embodiments of the invention encompass arrangements in which the functions performed under the role of the IPSP can be carried out by an organization that is also the merchant and / or also the acquirer.

Because transactions, which are authorized using the system of the present invention, are still processed by the commercial IPSP system, the commercial IPSP functions related to these transactions can be accessed by online commerce using a common interface for different transaction types. These types of transaction can include both types of transaction for which payment authorization requests originate via the trusted intermediary system and other types of transaction, separately authorized, which can be processed by the IPSP for the benefit of the trade without going through the reliable intermediary system. This common interface can comprise a secure online website.

In at least one arrangement, the trusted central intermediary system receives a payment authorization response from the selected commercial IPSP system, and in response transmits a payment authorization response to the first online commercial system. Furthermore, the method comprises receiving an online business identity from the first online business system, the online business identity is included in the generated authorization request which is generated based on the received online business identity. Therefore, since the trusted intermediary system interfaces with, rather than replaces, an existing IPSP system of online commerce, the account identifier of online commerce is the one that is transmitted to the acquiring bank. As a result, the relationship for such transactions is between the buyer and online commerce, with the resulting benefit that the buyer is protected by the rules of the card scheme and, in some eventualities, they comply with any applicable consumer protection. In addition, the commercial IPSP system may provide one or more additional transaction processing functions, such as settlement, chargeback handling, refund handling, and transaction reporting, for the benefit of the online business system. In particular, the commercial IPSP system can provide online commerce with a secure online website to approve chargebacks, initiate refunds, and / or view transaction reports regarding authorized transactions through the system of the present invention.

Preferably, the step of retrieving transmission data to enable transmission of payment authorization request data to a selected commercial IPSP system associated with the first online trade comprises retrieving a network address for the selected commercial IPSP system on the basis of the commercial IPSP system registered by the first online commerce, and the step of transmitting the generated payment authorization request to the selected commercial IPSP system comprises transmitting the generated payment authorization request based on the retrieved network address. Network addresses are preferably populated on an online commerce basis, for example when a given online commerce is registered with the trusted intermediary system, providing a convenient centralized mechanism to control the flow of payment authorization requests. Accordingly, the trusted central intermediary system preferably provides a registration interface for online merchants whereby a given online commerce can register a commercial IPSP system with which the online commerce is associated.

In at least some arrangements the trusted central intermediary system can cooperate with a plurality of issuing authentication systems, each being responsible for conducting authentication for a different issuing bank, the method comprises the step of selectively communicating with a respective issuing authentication system to verify the identity of the holder of financial instruments. This user verification can be performed using the known 3-D Secure method, and can be performed when, for example, the user adds a payment instrument to his user wallet via the registration interface mentioned above.

The user can register with the trusted intermediary system via various different mechanisms, including: direct with the intermediary system; indirect via a trusted third party; and redirection via an online banking service. Regarding the third alternative, the method comprises the step of recovering a financial instrument identity that is used in the payment authorization request generated based on the authentication of the instrument holder by one of the plurality of issuing authentication systems. selected. After the data is transmitted to the holder of financial instruments, the holder of financial instruments is enabled to perform authentication with respect to a selected authentication system, and the authentication response data is received from the selected authentication system in response to the authentication of the holder of financial instruments by the selected issuer authentication system. In addition, embodiments of the invention may include receiving data indicating a financial instrument identity that is used in the payment authorization request generated from the selected issuing authentication system in response to the authentication of the financial instrument holder by the authentication system. selected issuer.

In accordance with further aspects of the invention, a trusted intermediary system is provided in communication with a plurality of commercial online systems and a plurality of commercial IPSP systems, the trusted intermediary system is arranged to conduct the steps of the aforementioned trusted intermediary system.

Furthermore, an online trading system is provided in communication with a trusted intermediary system and a plurality of commercial IPSP systems, the online trading system is arranged to conduct the stages of the aforementioned online trading system. Still further a commercial IPSP system is provided in communication with a trusted intermediary system and a plurality of online commercial systems, the commercial IPSP system is arranged to conduct the stages of the aforementioned commercial IPSP system.

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

Additional 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 is made with reference to the accompanying figures.

Brief Description of the Figures

Figure 1 is a schematic diagram showing a conventional payment system;

Figure 2 is a schematic diagram showing a payment system according to an embodiment of the invention;

Figure 3 is a schematic flow diagram showing the flow of data during use of the payment system of Figure 2 according to an embodiment of the invention;

Figure 4 is a schematic block diagram showing components of the reliable intermediary system of Figure 2 according to an embodiment of the invention;

and

Figure 5 is a schematic timing diagram showing the message flow between selected components of the payment system of Figure 2 according to an embodiment of the invention.

Detailed description of the invention

As described above, the embodiments of the invention relate to a payment system and method, specifically a payment authorization request processing system and method for payment transactions that are conducted via a data communications network for the benefit of online shops. The system involves a new transaction identity, referred to herein as a reliable intermediary system, which cooperates with the conventional payment entities described in the background section with reference to Figure 1.

Figure 2 represents a schematic illustration of a payment system 1 according to an embodiment of the invention. The trusted intermediary system 10 is shown transmitting payment authorization requests to each of a plurality of different commercial IPSP systems 3a ... 3c. Each of the la ... le commercial online processing systems is associated with one of the 3a ... 3c commercial IPSP systems as indicated by the dotted line

Ll for one of the online shops le, as well as is associated with one of the acquiring banks 5c, as indicated by the dotted line L2, again for online trading le. At least some of the 3b, 3c commercial IPSP systems can be arranged to transmit payment authorization requests to more than one acquiring bank: this reflects the fact that more than one online merchant can process their payments via a given commercial IPSP system; each business has an account with a particular purchasing bank.

In addition, each order transmission web page of the website of the online trading system the ... includes, as a new payment option, referred to herein as the Secure Payment System (SSP), this identifies the payment via the reliable intermediary system 10. Other payment options, including conventional online payment options, may also be included whereby a buyer may select a payment option which does not involve payment authorization that is processed through the trusted intermediary system 10. Such separately authorized transactions, for example, may include 5 conventional online payment options in which a buyer enters their payment details into the online merchant system directly, or the commercial IPSP system directly, rather than using the intermediary system. reliable 10. With respect to such transactions, the trusted intermediary system 10 interfaces with, rather than replacing, the online commercial IPSP system 3c, which may be the existing commercial IPSP system of online commerce when subscribing to the service provided by the intermediary system reliable 10. That is, because payment systems according to the modalities of the invention involve the addition of the reliable intermediary system 10 within a set of existing and known processing entities, payments can be made according to conventional methods using the second and third types of arrangements described with reference to Figure 1 in addition to, or as an alternative to, via the trusted intermediary system 10.

The trusted broker system 10 maintains the data in a DB1 database corresponding to the users (buyers) and online merchants that have registered with the broker 10, along with the transaction data. As will be described in more detail below, the DB1 database maintains a set of payment details for the user in the form of a set of stored records conveniently referred to herein as a remote store or user wallet; Users can add details of payment instruments (typically cards and accounts) from which they can select to make payment for a transaction, causing the trusted intermediary system to update the contents of the user's remote store. Since the trusted intermediary system 10 maintains a range of payment instruments available to the user, the user can select a payment method on a per transaction basis. Accordingly, the provided online merchants subscribe to the trusted intermediary system 10, users only have to submit their respective payment details once, to a single entity, removing the user requirement to provide payment details to individual online merchants. every time they buy online. This has the benefit of reducing the risk of fraud that may be incurred in relation to conventional payment system arrangements (such as that shown in Figure 1).

Because transaction authorization requests which originate using trusted broker system 10 are passed and processed by IPSP system 3c, the various additional transaction processing IPSP functions related to these transactions can be entered by the merchant at line via reliable intermediary system 10. The commercial IPSP 3c system may provide one or more of such additional transaction processing functions, eg settlement, chargeback handling, refund handling, and transaction reporting, for the benefit of the online business system le. The commercial IPSP 3c system preferably provides online commerce with a secure online website to approve chargebacks, initiate refunds, and / or view transaction reports related to authorized transactions through the trusted intermediary system 10.

Furthermore, since the transaction authorization requests which originate using the trusted intermediary system 10 are passed and processed by the IPSP system 3c, the functions of the IPSP related to these transactions can be entered by the online commerce using an interface of IPSP system which is common for different types of transaction, including both types of transactions authorized via the trusted intermediary system 10 and other types of transaction, separately authorized, which can be processed by the IPSP for the benefit of the trade without going through the trusted intermediary system 10. Such separately authorized transactions, for example, may include transactions for which a buyer enters their payment details into the commercial system at line you directly, or the commercial IPSP 3c system directly, for use in payment authorizations conducted by the commercial IPSP system you.

Still further, the online commerce internet account identifier is the one that is transmitted to the acquiring bank 5c by the commercial IPSP system 3c as part of the payment authorization request. This has the benefit of ensuring that the buyer is protected by the card scheme rules and, in some eventualities, complying with any applicable consumer protection; in addition, each transaction can be identified on an online commerce basis in the user's card account statements.

As can be seen from Figure 2, specifically the dotted line L3, the trusted intermediary system 10 connects to the issuing bank system 9a (while only one connection is shown, it will be understood that there may be a connection between the trusted intermediary system and any number of issuing bank systems). This connection facilitates the verification of the cardholder_ (buyer) using the well-known 3-D Secure authentication mechanism. The protocol for 3-D Secure is documented in US patent application 10 / 156,271, published under publication number US2002 / 0194138 in the name of Visa International Service Association, the content of which is incorporated by reference herein. In its whole. The protocol uses messages (typically XML messages) sent over the connections of

Secure Socket Layer (SSL), as documented in the aforementioned patent publication as the Service of

Payer Authentication (PAS). This service can be used when the trusted intermediary system 10 determines that a given requested transaction corresponds to the predetermined level of risk, such as may be the case for transactions involving the shipment abroad of high-value goods. The means by which risk assessment is performed and indeed a given level of risk for a given transaction is described in more detail below.

Card scheme system 7 communicatively connects to trusted broker system 10 as shown schematically by dotted line L4; this indicates that trusted broker system 10 has subscribed to an account update service (not labeled in Figure 2, but described with reference to

Figure 4 below as part 415d) provided by the card scheme system 7 and therefore receives updated card information, for example when a card is lost, stolen, or expired, and has therefore been reissued to the user. An example of such a service is the Visa Account Updater (VAU) service, while another is the MasterCard Automatic Billing Updater.

In a fix the interface for the account update service provided by the card scheme system 7 is batch oriented: the trusted broker system

10 submits a request or requests to the card scheme system 7, the request includes details of certain users registered with the system 10. A batch interface is typically used (for example, Secure File Transfer Protocol (SFTP) or Connect: Direct<sup>tTM1</sup>) to send the request files to the account update service, which is responsible for providing the details of the reissued cards. After an interval the trusted intermediary system 10 enters the account update service and collects the response files, then updates the payment instruments locally for the relevant subscribers to the SSP system.

Alternatively the interface may be message based so that individual Primary Account Numbers can be verified or updated in real time. As an alternative to submitting the request directly to the card scheme system 7, the trusted intermediary system 10 may emulate the operation of an online trade request submission to the known acquiring bank systems 5a ... 5c, for subsequent transmission. to card scheme system 7.

Referring now to Figure 3, the operation of payment system 1 in accordance with one embodiment of the invention will now be described. In step S301 the user completes his shopping experience with the online trading system of the online trading C's, initiates the payment using the online trading system, and proceeds to the virtual payment, according to the conventional methods available through the commonly available shopping cart and payment software packages as known to the skilled person. The user selects Secure Payment System (SSP) as a payment option (step S301), causing the online trading system to transmit a payment authorization request message originating to trusted intermediary system 10 (step S303); the originated request message comprises at least a payment amount for the selected merchandise, the online merchant account identifier and an identifier for the order. The trusted broker system 10 then transmits a login URL to the user (step S305), prompting the user to login, or, if it is their first time selecting SSP as a payment option, register with the trusted broker system 10 . Assuming the purposes of this example that the user has previously registered with the service, the user enters their login credentials (for example, username, password, or other authentication details, depending on the authentication mechanism used by the Reliable Intermediate System 10 - Step S307).

The trusted intermediary system 10 then performs a query based on the user's identification details and credentials (step S309), retrieving the details of the user's remote store from the database.

DB1, and presenting the same to the user for their payment method selection (step S310). In selecting the desired payment method from the options provided according to the details retrieved from the user's remote store, the trusted intermediary system 10 sends a payment authorization request message to the IPSP system of online merchant 3c, the request message authorization method comprises the details of the selected payment instrument, the required payment amount and the online business identifier (step S311). The system

Commercial IPSP 3c sends a request for additional payment authorization to the relevant acquiring bank 5c (step S313), encouraging authorization (or otherwise) by conventional methods (step S315) and transmitting a response message from the acquiring bank 5c to the 3c commercial IPSP system (step S317). Assuming that the response comprises the confirmation of the authorized payment, in step S319, the commercial IPSP system 3c sends a payment success notification message to the trusted intermediary system 10. This payment success notification message comprises a reference for card scheme authorization and a transaction identifier for card scheme transaction.

The trusted intermediary system 10 then sends a payment success confirmation message to the online trading system le (step S321), which encourages the online trading system to confirm the status of the order to the user (step S323).

It will be appreciated from the above that conventional online commercial systems (including its commercial IPSP system) require modification to include Secure Payment System (SSP) as a payment option and in effect to interconnect with the trusted intermediary system 10. Consequently, the commercial IPSP system exposes a payment authorization service to the trusted intermediary system 10 that allows payment and settlement by payment instruments (typically cards and bank accounts). It will further be appreciated that because the trusted intermediary system 10 integrates with many commercial IPSP systems, it accordingly comprises a plurality of interface protocols and formats, each corresponding to a respective commercial IPSP system. Furthermore, each online trading system is configured with integration software components, for example in the form of plugins, which enables online trading to integrate with the trusted intermediary system 10 for the purpose of initiating a payment transaction using SSP as a payment method.

The details of the processing and configuration capabilities of the trusted broker system 10 will now be described with reference to Figure 4. The trusted broker system 10 comprises connectivity and presentation processing components, which are configured to transmit and handle various user-specific and online business-specific data; These processing components will be explained in more detail later, but in the general review they comprise the following:

User registration data and components

When a user wishes to register with the trusted intermediary system 10, an account registration process is required that allows the user to create an account with the SSP service. The account is required to be populated with appropriate data that can be used to make payments from the SSP service of an online trading system that offers the service.

Once registered, each user has a set of records associated with it, which stores the details of the accounts to which they want to charge a sum when they carry out a financial transaction. This may be a bank account, a payment card, or another account such as any payment instrument to which a unique account reference can be given. The trusted intermediary system 10 comprises display components 404 that enable the user to select and add / remove from the list of payment instruments. In addition the user has

<td>tickets</td><td>of</td><td>notebook</td><td>of</td><td>addresses,</td><td>the</td><td>which ones retain</td>

<td>details</td><td>of</td><td>Shipping;</td><td>the</td><td>components</td><td>of</td><td>presentation 404</td>

<td>enable</td><td>to the</td><td>user</td><td colspan="4">to modify shipping details. Every</td>

User has a profile, which comprises identification and demographic data for the user, and can be modified via display components 404, while user transaction data can be viewed for user review. As shown in Figure 4 and explained in more detail later, the trusted intermediary system 10 can be implemented as a web server, in this case the presentation components

404 they interoperate with the user's search engine to allow the selection and modification of user data in the manner just described. However, user registration with trusted broker system 10 can be done via any suitable alternative interface.

Registration can be done via a number of channels:

• Registration via SSP site - the user registers on the website of the trusted intermediary system 10 and is presented with a registration page designed to capture the details of the user's preferred payment instrument and identity • Redirection from another system - If the user you are in the online commerce order system and you want to make the payment using the SSP option you will need to register if you have not done so. The user is redirected to the registration screens associated with the trusted intermediary system 10 and then redirected back to the online trading system.

• Registration via an online bank - assuming that the trusted intermediary system 10 understands the necessary integration functionality, the user can register for the SSP service within the bank's online account service.

User authentication components

Authentication of a user in the trusted intermediary system 10 for payment transactions can be performed according to any of the 3 known categories listed below:

Authentication factor 1 - Sometimes the user knows (for example, a username and password, phrase that contains the password, a personal identification number (PIN))

Authentication factor 2 - As the authentication factor

1, more, sometimes the user has (eg ID card, security token, software token, phone, or cell phone)

Authentication factor 3 - As the authentication factor

2, moreover, sometimes the user is or does (eg, retinal or fingerprint pattern, DNA sequence (these are classified definitions of what is sufficient), voice or signature recognition, unique bioelectric signals, or other biometric identifier) .

An example of a mechanism to enable authentication is the 3-D Secure service mentioned above - provided by the trusted intermediary system 10, the issuing bank suggests to the buyer a password that is known only to the bank and the buyer. Since the merchant does not know this password and is not responsible for capturing it, it can be used by the issuing bank as evidence that the buyer is indeed its cardholder.

In one mode the trusted broker system implements the authentication process. Alternatively the user can initiate transfer via their online banking details, in this case the user could log in to their online bank account, where the banking system software could redirect the user back to the trusted intermediary system 10. As a further alternative, authentication may involve an account identification entity, which, based on the user's specific input, may act as an intermediary and cooperate with the trusted intermediary system 10 to effect identification of the user's account on benefit of the user.

Online trade data warehouse:

The trusted intermediary system 10 stores the online trade profile and registration data. This data includes an online commerce internet account identifier along with a network and transaction identifier of the commercial IPSP system 3c with which the online commercial system registers. This data is retained to enable the trusted intermediary system 10 to communicate with the commercial IPSP system 3c for the benefit of the online commercial system, and is collectively referred to as commercial IPSP system transmission data, or simply transmission data. Furthermore, the trusted intermediary system 10 comprises a payment authorization service through which the trusted intermediary system 10 makes payments for the benefit of online commerce. Furthermore, because the trusted intermediary system 10 integrates with many commercial IPSP systems it comprises a plurality of protocols and interface formats. Details of the protocols and formats relevant to each commercial IPSP system are retained in the online commerce data warehouse. Accordingly, the aforementioned transmission data comprises a mapping of a payment authorization request emanating from an online business system given to an IPSP identifier, a network address and / or network protocols that enable authorization requests to be routed to the relevant commercial IPSP system.

Therefore, it will be appreciated that the registration of any given trade that offers the SSP service involves the trade that specifies the commercial IPSP system to which to subscribe. Conveniently, trusted broker 10 can retain a set of records corresponding to active commercial IPSP systems: each record set can comprise network identifier and 'communication protocols required for storage in DB1 database by trusted broker 10. Accordingly, during registration with the SSP the given online commerce may select, for example, via a drop-down list coordinated by the presentation components 404 of the trusted broker 10, the commercial IPSP system to which the online commerce has subscribed; the corresponding transmission data (or a link to it) can then be stored in conjunction with the trade records retained in the DB1 database. Accordingly, whenever the given online commerce specifies its corresponding commercial IPSP system in the manner just described, then in response to receiving a request for payment authorization from the commercial system, the trusted intermediary 10 can make an appropriate inquiry of the database and retrieve the network identifier, protocol requirements, etc. of the corresponding commercial IPSP system.

Application Programming Interface (API) services adapter

The trusted intermediary system 10 comprises an API Service Adapter, which enables connectivity between the trusted intermediary system 10 and the messaging infrastructure of the payment system 1. The adapter is configured to handle compliance of requests from trusted broker system 10 to external services, such as payment authorizations to commercial IPSP system 3c, and to expose a set of trusted broker system 10 services that can be used by external functions. such as the commercial 3P IPSP system.

Specific data and components of the transaction:

The trusted broker system 10 stores transaction data such as payment authorizations and account statements that are handled by the trusted broker system 10. In addition, the trusted broker system 10 can store audit data associated with online trading users and activity in line as well as general system activity.

Courier services

The trusted broker system 10 is configured with email agents, who compose and transmit emails for the purposes of email address authentication and purchase order confirmations and user activation.

As mentioned above the trusted broker system 10 is preferably included as a web application server, for example as a J2EE 401 compliant application server which manages and provides access to the common business logic of the platform, and a web server and J2EE 403 servlet engine, which acts as the entry point for external HTTP requests to trusted broker system 10 from online merchants and user browsers.

The web server and servlet engine 403 comprise presentation components, which expose API wrappers or payment APIs based on web services to online business systems. Also, the web server and servlet engine

403 comprise presentation processing components

404 which are configured to generate and manage the user interface, for example, when the user selects a payment method in the manner described above.

The J2EE 401 Application Server handles all the business logic for the applications and web platform. The business logic comprises functional software components 411a ... 411e, which can be implemented, for example, as Session Java Beans (EJBs). These functional groups include, for example, email processing modules, address validation modules, and anti-fraud and security service modules; in addition server 401 comprises objects implemented, for example, as EJB 3.0 specific Java objects 411f ... 411h that provide access to persistent and static data stored in DB1 such as user data, audit data and transaction data described above . The trusted broker system comprises web services in the form of wrappers that expose Session EJBs to other elements of payment system 1. More specifically, the 411a functional software components. . . 411e interpolate with external 405 service enablers such as 415a address validation services, email applications (including access to an email server) 415b, 3-D Secure 415c services, 415d account update services, and services against fraud 415e, among others. The application server components 401 411a ... 411e communicate with the application components 415a ... 415e via a set of APIs, generically referred to, such as in relation to parts 413a ... 413e. When implemented as a web server, the data between the elements of the payment system 1 (that is, those shown in Figures 2 and 3) and the trusted intermediary system 10 are transmitted using a secure mechanism, for example via HTTP over the Secure Socket Layer (HTTPS) protocol.

In the case of the 3-D service functional component

Secure 411c, this component uses, or cooperates with, risk-based rules which are invoked to determine whether or not the component is. shall involve interactions between the user and the trusted broker 10. Rules are typically configured under the control of 415e fraud services, and for example, may specify that the 3-D Secure method should be invoked when a user registers an instrument paid with the service

SSP (to ensure that the user is the legitimate cardholder); for the first transaction that a buyer makes; for transactions that exceed a certain value, for transactions that involve the shipment of merchandise outside the buyer's domestic territory); and for certain types of merchandise and / or services. Other events that can trigger the 3-D Secure service, including invoking the service for all transactions, will be apparent to one of skill in the art.

Returning to the functional account update component (AU) 4 lid and corresponding service 415d provided by the card scheme system 7, the AU component 411d comprises routines to routinely review the expiration dates of payment instruments stored in wallets of individual users in the DB1 database, and submit requests to the card scheme system 7 with details of users whose payment instruments are due within a specified time window. The AU 411d component subsequently accesses the account update service 415d and collects a generated response file, and updates the payment instruments in the relevant user wallets based on the content of the response file.

The processing steps described above with reference to Figure 3, specifically the steps performed in particular by the trusted intermediary system 10 when interconnected with the various payment entities, will now be described in more detail. Returning to Figure 5, in step S5.1, the user selects the SSP payment service as the payment method and submits his selection to the online commerce website. This triggers a request from the online trading system, specifically retrieval by the online trading system of the corresponding URL for a trusted broker 10 login page, and then sending a key order plus trade fields in line including a return URL (step S5.3) and creating a secure session. Having received the login URL from the trusted broker system 10, the online trading system displays the login page to the user (step S5.5). In an arrangement the login page is implemented as an iFrame, which enables the user to communicate directly with the trusted broker system 10 which remains within the online environment of online commerce. The user enters their 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 they send the data contents of the user's remote store to the iFrame for display and selection in this (step S5.ll). Once the user has selected his payment method of the options within the downloaded remote store contents, the user presents his selected option (step S5.13) to the web server and servlet engine 4 03, resulting in a confirmation page which is transmitted to the iFrame (step S5.15).

Once the user has confirmed the payment selection and presented it (step S5.17), the web server and servlet engine 403 send the payment details to the IPSP system of online commerce 3c (step S5.19) via a payment authorization service through which the reliable intermediary system 10 makes payments for the benefit of online commerce. Under certain circumstances the application server 401 invokes a responding 3-D Secure process upon receipt of the payment selection in step S5.17. For example, application server 401 may invoke the 3-D Secure 411c component, which, based on the content of the payment request message, determines whether or not the user will be verified by the corresponding issuing bank before proceeding with the processing of the transaction. In the event that the 3-D Secure 411c component determines that the transaction presents a predetermined level of risk (based on the rules accessible to component 411c), the 3-D Secure 411c component configures a secure communication between the user and a Corresponding 3-D Secure Issuing Bank Authentication System

415c. For example, a transaction using Verified by

Visa / SecureCode will initiate a redirect to the issuing bank's website, or initiate upload of an online framework session, to authorize the transaction.

Assuming that the user is verified, or in case the verification is deemed unnecessary for the transaction in question, step S5.19 involves creating an authorization request for receipt by the payment APIs 4 06, converting the payment authorization request in the online commerce API format and transmit the formatted request to the commercial IPSP 3c system. A statement request is also transmitted to the payment APIs 406, which convert the statement request into the online commerce API format API and transmit it to the commercial IPSP 3c system. It will be appreciated that communication can be accomplished by either dual or single message implementations. These formatting and transmission actions are recorded in the transaction data store held by the trusted intermediary system 10 corresponding to the online trading system.

In the notification of payment request authorization (step S5.21), the web server and servlet engine 403 transmits an online commerce URL back to the iFrame (step S5.23), along with the notification of successful authorization, causing the iFrame to empty, reload with JavaScript code from the online trading system (step S5.25), and therefore remove the iFrame and return the user to the website of the online trading system. Finally, the online trading system website displays a successful ordering web page in step S5.27.

In parallel with steps S5.13-S5.19, application server 401 can initiate user activity and send it to the audit data store, while sending the corresponding event and system information to a notification system of fraud by third parties (represented by one of the common 415e service enablers shown in Figure 4). The fraud notification system comprises, but is not limited to, a fraud risk engine, which performs fraud analysis to generate a risk log and recommended action for the transaction; Appropriate fraud notification systems such as that provided by RSÁ ™ in its fraud prevention package are known and will not be described in further detail herein. The risk and action log is stored in the DB1 database, along with the other transaction details for online commerce and the user.

The above embodiments will be understood as illustrative examples of the invention. Additional embodiments of the invention are contemplated. For example, while in the above examples the trusted intermediary system 10 is described receiving payment request from online commercial systems, the intermediary 10 may additionally or alternatively receive payment requests from a commercial IPSP system in the third type of arrangement described in the background section in cases where such commercial IPSP systems have been modified to offer SSP as a payment option.

Furthermore, while the preferred modalities

0 they make use of web technology. iFrame to make the user navigate to different websites, it will be appreciated that standard web redirection can be used instead. In such alternative arrangements the user's browser will navigate away from and back to the SSP website, depending on the entity (or rather the URL corresponding to it) with which the user's browser is communicating at any point in time. For example, during authentication and / or account selection by the user, the user's browser may be redirected by the SSP website to a website provided by, or for the benefit of, the user's issuing bank, and once User authentication and / or account selection is performed, the user's browser can be redirected through the issuing bank's website back to the SSP website.

In the above modalities the trusted broker system 10 is described by storing shipping details in the user recordset: to this extent the trusted broker system 10 can be seen providing some of the functionality associated with a verification tool: the relevant fields stored in the DB1 database may be made available through the interface to enable commercial systems to reference the data during the verification process and populate the fields appropriately. However, it will be understood that this is an optional aspect of broker 10. Indeed, the verification functionality may be provided by the online trading system, in this case the trusted intermediary system 10 could simply play the role of a payment tool, and the DB1 database could then store few items of information. user specific.

In the above, the term system, when applied to entities such as the commercial system, the commercial IPSP system, the trusted intermediary system and other entities, should be understood to mean a data processing function, provided at one or more sites. Physical, connected to other data processing functions via data communication links. Each function can be provided by a single data processing node, for example a server computer, or a set of data processing nodes that provide backup in case of failure with each other, such as a cluster of server computers, and / or or a set of interconnected data processing nodes that provide different modular sub-functions with respect to other members of the set, for example, an interconnection set of different server computers.

As will be appreciated from the foregoing, communications between the various entities comprising payment system 1 preferably proceed via a data communications network such as the Internet. Each of the payment system 1 entities (the issuing bank; the trusted intermediary; the acquiring bank processor; the commercial IPSP systems; and the online commercial systems) is identifiable via a network identifier such as an address Internet Protocol (IP) or other suitable identifier.

Accordingly, the communication network may comprise a network comprising one or more technologies, ie hybrid communication network; for example, the network may comprise the Internet in conjunction with the Public Switched Telephone Network (PSTN) and / or a mobile communication network capable of supporting, for example, one or more of the following protocols: GSM (Global System for Mobile Communications ),

WCDMA (Broadband Code Division Multiple Access), GPRS (General Packet Radio Service). In addition to or instead of the mobile communication network, a local area network such as a Local area network

Wireless (WLAN) or BlueTooth® (BT) and / or other technologies such as WiMax can be used to carry part of the payment authorization request and response messages. In this way, users can interact with online business systems using remote portable devices. The data communications network can be arranged to support generic Internet access using any of the transportation methods. In addition, or as an alternative, to sending confirmation messages as email messages, payment confirmation messages can be transferred as SMS messages (Short Message Service), MMS messages (Multimedia Service), Application Protocol pages Wireless (WAP), Internet pages, HTML (Hypertext Markup Language) pages, XHTML (Extended HTML) pages, or IP (Internet Protocol) datagrams.

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

Contents3

3 priority claims, no other members on record

This recordMember, by publication datePriority claim

Priority claims3

Priority claims
Document	Office	Kind	Date
0900150	United Kingdom	A	2009-01-06
41683609	United States of America	A	2009-04-01
2010050079	European Patent Office (EPO)	W	2010-01-06