MX2011007256A - Sistema de pago. - Google Patents

Sistema de pago.

Info

Publication number
MX2011007256A
MX2011007256A MX2011007256A MX2011007256A MX2011007256A MX 2011007256 A MX2011007256 A MX 2011007256A MX 2011007256 A MX2011007256 A MX 2011007256A MX 2011007256 A MX2011007256 A MX 2011007256A MX 2011007256 A MX2011007256 A MX 2011007256A
Authority
MX
Mexico
Prior art keywords
payment
online
commercial
ipsp
request
Prior art date
Application number
MX2011007256A
Other languages
English (en)
Inventor
Peter Winfield-Chislett
Itamar Lesuisse
Veronica Casabonne
Raymond Tamblyn
Original Assignee
Visa Europe Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa Europe Ltd filed Critical Visa Europe Ltd
Publication of MX2011007256A publication Critical patent/MX2011007256A/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0613—Third-party assisted
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting

Abstract

Las modalidades de la invención proporcionan un método de procesamiento de solicitudes de autorización de pago para 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. El método se conduce por un sistema intermediario central confiable el cual se arregla para 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 línea; cada sistema IPSP comercial 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, y 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. 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 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. Las modalidades de la invención habilitan a un usuario para seleccionar un método de pago en una base por transacción, mientras remueve el requerimiento que el usuario proporcione detalles del pago a sistemas comerciales en línea individuales o a sus sistemas IPSP comerciales. Por consiguiente, siempre que los comercios en línea, o sus IPSP comerciales, se suscriban a un servicio arreglado para realizar el método, los usuarios solamente tienen que presentan sus detalles de pago respectivos, preferiblemente solo una vez, a una entidad confiable separada.

Description

1 SISTEMA DE PAGO CAMPO DE LA INVENCIÓN La presente invención se refiere a un sistema y método de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos en beneficio de comercios en linea, y es particularmente, pero no exclusivamente, adecuado para el procesamiento de pedidos hechos por titulares de instrumentos financieros.
ANTECEDENTES DE LA INVENCIÓN Los usuarios son fomentados incrementadamente a comprar mercancías en línea, es decir vía la Internet y tecnologías asociadas. Generalmente hablando, los sistemas de pago en línea existentes caen en uno de tres tipos de arreglos: en un primer tipo de arreglo, un sistema comercial en línea colecta los detalles del pago de un titular de instrumentos financieros, de otra manera conocido como un comprador o titular de la tarjeta, sin que el comprador trate directamente con alguna otra entidad que puede estar involucrada en la transacción, y el sistema comercial en línea envía los detalles de la transacción directamente a su sistema de banco adquisidor. En un segundo tipo de arreglo, el sistema comercial en línea colecta los detalles del pago 2 de un comprador sin que el comprador trate directamente con alguna otra identidad que puede estar involucrada en la transacción, y el sistema comercial en linea envía los detalles de la transacción a un Proveedor de Servicios de Pagos por Internet comercial en línea (IPSP) el cual procesa las autorizaciones de pago en beneficio del comercio. El sistema IPSP comercial posteriormente transmite los detalles al sistema de banco adquisidor del comercio en línea; los detalles se pueden transmitir directamente al banco adquisidor o a un procesador de pagos el cual actúa en beneficio del banco adquisidor. Los ejemplos de los sistemas IPSP los cuales proporcionan soporte para este segundo tipo de arreglo incluyen el sistema de Pagos Protx™ Veri-Secure (VSP) .
En un arreglo del primer y segundo tipo, el sistema comercial en línea típicamente obtiene datos de tarjeta de pagos, información de la cuenta de banco y/u otros datos financieros del comprador. El sistema comercial en línea luego pasa esta información ya sea directamente, o vía el sistema IPSP comercial, a un sistema de procesamiento del banco adquisidor. Cada sistema comercial en línea es asignado con un identificador de cuenta comercial en línea por un banco adquisidor, y este identificador de cuenta se usa para identificar el comercio en línea para el banco adquisidor cuando solicita la autorización de una transacción. 3 La Figura 1 muestra un ejemplo de sistemas de pagos en línea convencionales de acuerdo con los arreglos del segundo tipo, que comprenden una pluralidad de sistemas comerciales en línea la, Ib, le. En este arreglo cada uno de los comercios en línea es una asociación operativa con un sistema de Proveedor de Servicios de Pagos por Internet comercial en línea (IPSP) 3, el cual es una puerta de acceso de pagos seleccionada y suscrita por el comercio en línea para los propósitos de conducir negocios seguros en la Internet. Mientras que la figura muestra cada uno de los sistemas comerciales en línea la ... le estando asociados con el mismo sistema IPSP comercial 3, alternativamente, y de hecho frecuentemente en la práctica, los sistemas comerciales en línea son enlazados a diferentes sistemas IPSP comerciales 3. Cada sistema IPSP comercial 3 proporciona un sistema que pasa los datos de la tarjeta de pago, solicitudes de autorización, y respuestas de autorización sobre la Internet usando tecnología de encriptación. La información de la transacción se envía por el sistema IPSP comercial 3, vía un enlace de comunicaciones de datos, al banco adquisidor 5, y por lo tanto al sistema de esquema de tarjeta 7 el cual intermedia con un banco emisor donde la validez de la tarjeta se comprueba y la disponibilidad de fondos en esta cuenta se verifica. Un código de autorización se regresa al sistema IPSP comercial 3; la autorización se encripta por el sistema 4 IPSP comercial 3 y se transmite en forma encriptada al sistema comercial en linea la, el cual activa el cumplimiento del pedido.
Una transacción en línea de extremo a extremo convencional usando un arreglo del segundo tipo e involucrando las entidades mostradas en la Figura 1 comprende las siguientes etapas: * Un sitio web del sistema comercial en línea la colecta de un comprador una o más selecciones de pedido. El comprador paga, ingresa sus detalles de pago y hace un pedido en el sitio web del sistema del comercio en línea 1 presionando el botón 'Entregar Pedido' o equivalente en la página web de transmisión de pedidos del sitio web del comercio.
* El buscador web del comprador encripta la información para ser enviada entre el buscador y el servidor web del comercio en línea.
* El comercio en línea luego transmite los detalles de la transacción a su sistema IPSP comercial 3, típicamente vía otra conexión encriptada al servidor de pagos alojado por el sistema IPSP comercial 3.
* El sistema IPSP comercial 3 transmite la información de transacción, incluyendo el identificador de cuenta de internet del comercio en línea, al procesador usado por el sistema de banco adquisidor del comercio en línea 5.
El procesador 5 transmite la información de transacción al sistema de esquema de pagos 7 (por ejemplo, Visa/MasterCard) .
El sistema de esquema de pagos 7 enruta la transacción al sistema correcto del banco emisor de la tarjeta 9. El sistema de pagos de banco emisor de la tarjeta 9 recibe la solicitud de autorización y envía una respuesta de nuevo al procesador del sistema de banco adquisidor del comercio en línea 5 con un código de respuesta 5.
El procesador del sistema de banco adquisidor del comercio en línea 5 transmite la respuesta al sistema IPSP comercial 3.
El sistema IPSP comercial 3 recibe la respuesta, y la transmite al sistema del comercio en línea donde se interpreta y una respuesta relevante luego se retransmite, vía el comercio al comprador confirmando que la transacción se ha autorizado.
El sistema IPSP comercial 3, en beneficio del comercio en línea, presenta todas sus autorizaciones aprobadas al sistema de banco adquisidor del comercio en línea 5 para liquidación.
El sistema de banco adquisidor 5 deposita el total de los fondos aprobados menos cualesquiera honorarios y cargos en la cuenta asignada del comercio en línea. Esta 6 podrá ser una cuenta con el banco adquisidor si el comercio en linea hace sus actividades bancarias con el mismo banco, o una cuenta con otro banco.
Una ventaja de usar una puerta de acceso de pagos tal como el sistema IPSP comercial mostrado en la Figura 1 es que el sistema IPSP comercial puede proporcionar una o más diversas funciones de procesamiento de transacción adicionales, por ejemplo liquidación, manejo de devoluciones de cargos, manejo de reembolsos, e informe de transacciones, en beneficio del comercio en linea. En el procedimiento de liquidación, el sistema IPSP comercial 3 presenta todas las autorizaciones aprobadas del comercio en linea colectadas durante un periodo dado, en un "lote", al sistema¦ de banco adquisidor del comercio en linea 5 para liquidación. Una devolución de cargo es una revocación de una transacción de tarjeta de pago iniciada por el comprador o el banco que emitió la tarjeta usada en la compra. Esto difiere de un reembolso, el cual es acordado e iniciado por el comercio en linea, vía el sistema IPSP comercial 3. El informe de transacción involucra proporcionar una función de informe de resumen para transacciones acumuladas las cuales se han autorizado y opcionalmente liquidado vía el sistema IPSP comercial 3, de modo que un comercio, por ejemplo, puede seleccionar un intervalo de fechas y ver un resumen relacionado con todas las transacciones conducidas dentro del 7 intervalo de datos seleccionado. Un sistema IPSP comercial 3 puede proveer a un comercio en linea con un sitio web en linea seguro para aprobar las devoluciones de cargo, iniciar los reembolsos y/o ver los informes de transacción como se describe.
Sin embargo, en cada uno de los primer y segundo tipos de sistemas de pago descritos anteriormente, se requiere que un comprador proporcione su información de pago separadamente de las transacciones iniciadas con cada diferente comercio en linea. Por consiguiente, para cada nuevo comercio en linea con el que un comprador interactúa, incrementa el riesgo de exposición, malversación y/o uso fraudulento de los datos financieros del comprador.
En un tercer tipo de arreglo (no mostrado) el sistema comercial en linea redirige al comprador a un sitio web de sistema de pago alternativo con el cual el comprador interactúa para completar la transacción. El sistema de pago alternativo interactúa directamente con el usuario que proporciona el pago al sistema de pago alternativo ya sea directamente de su cuenta de banco o vía un mecanismo tal como una tarjeta de pago. Donde se usa una tarjeta de pago de un esquema de pago convencional, el sistema de pago alternativo desempeña el papel del comercio en el sistema de pago convencional, presentando una solicitud de pago a través de un sistema adquisidor. El pago del usuario se hace al 8 sistema de pago alternativo. El sistema de pago alternativo entonces es responsable de cualquier reembolso del comercio. En un segundo caso, el sistema de pago alternativo puede, en efecto, comportarse como una cámara de compensación convencional, financiando una cuenta del usuario dentro del sistema de pago alternativo de la cuenta de banco emisor actual del usuario cargando una suma directamente a su cuenta. El sistema de pago alternativo posteriormente asegura que el pago se envíe a la cuenta de banco emisor del comercio, usualmente a través de una cámara de compensación convencional. Esta cuenta de banco del comercio puede o no puede ser la misma como su cuenta retenida con su sistema adquisidor convencional. Por consiguiente, la mayoría de los sistemas de pago diferido del tercer tipo actúan como el intermediario para tomar los fondos actuales del usuario y pasarlos al comercio, más usualmente vía las cuentas de banco individuales del consumidor y comercio, potencialmente reteniendo aquellos fondos cuando pasan a través de las cuentas mantenidas por el sistema de pago; un ejemplo de este tercer tipo de sistema de pago incluye el sistema de pago PayPal'™' bien conocido. Tal sistema de pago también puede tener la capacidad de operar como un IPSP convencional, por ejemplo, proporcionando servicios de manejo de pagos en línea asociados .
Mientras que este tipo de sistema de pago alivia la 9 necesidad del usuario para establecer cuentas de pago individuales en una base de comercio en linea, el usuario tiene una relación con el sistema de pago alternativo y no con el sistema comercial en linea; esto causa varias desventajas notables: primero el comercio en linea no recibe el pago directamente de un banco adquisidor ni puede acogerse a una garantía de pago basada en el esquema de pago, debido a que para estas transacciones no existe relación directa entre el comercio y un esquema de pago con tarjeta. Segundo, para las transacciones efectuadas vía el pago con tarjeta el comprador no tiene visibilidad del comercio en línea individual del cual el producto fue comprado (en su lugar el estado de cuenta de la tarjeta identifica la entidad del sistema de pago alternativo) . Tercero, el comprador no es protegido por las reglas del esquema de la tarjeta y no se puede proteger por cualquier protección al consumidor aplicable, debido a que la transacción está con el sistema de pago, y no con el sistema comercial en línea.
Breve Descripción de la Invención De conformidad con al menos una modalidad de la invención, los sistemas y software se proporcionan para el procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una re de comunicaciones de datos en beneficio de comercios en línea, 10 como se especifica en las reivindicaciones independientes. Esto se logra por una combinación de características citadas en cada reivindicación independiente. Por consiguiente, las reivindicaciones dependientes prescriben implementaciones detalladas adicionales de la presente invención.
Más particularmente, los aspectos de la invención proporcionan un método para el procesamiento de solicitudes de autorización de pago para 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, 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 transmitir solicitudes de autorización de pago a cada uno de una pluralidad de diferentes sistemas Proveedores de Servicios de Pagos 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 que son responsables de procesar autorizaciones de pago para al menos uno de los bancos adquisidores, el método comprende: recibir desde un primer sistema comercial en linea, responsable de originar solicitudes de autorización de pago para un primer comercio en linea, 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 linea; 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 del instrumento financiero; y ii) una identidad de comercio en linea, asociada con el primer comercio en linea, 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 12 autorización de pago a un sistema IPSP comercial seleccionado asociado con el primer comercio en línea; y 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 linea se asocia.
Preferiblemente, 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. Los diferentes instrumentos financieros son ventajosamente retenidos en un almacén local, o cartera de usuarios, por el sistema intermediario confiable. Por consiguiente, las modalidades de la invención habilitan a un titular de instrumentos financieros, o usuario, para seleccionar un método de pago sobre una base por transacción, mientras remueve el requerimiento del usuario para proporcionar detalles del pago a sistemas 13 comerciales en linea individuales o sus sistemas IPSP comerciales. Por consiguiente, siempre que los comercios en linea, o sus IPSPs comerciales, se suscriban a un servicio arreglado para realizar el método, los usuarios solamente tienen que presentar sus detalles de pago respectivos, preferiblemente solo una vez, a una entidad confiable separada. Esto tiene el beneficio de reducir el riesgo de fraude en que se puede incurrir con relación a arreglos de sistemas de pago convencionales, mientras permite que los usuarios efectúen transacciones más rápidamente y convenientemente debido a que no hay necesidad que el usuario ingrese información personal y financiera con respecto de cada transacción.
En cuanto a la población de la cartera de usuarios con detalles de instrumentos de pago, el sistema intermediario central confiable preferiblemente proporciona una interfaz de registro para un titular de instrumentos financieros por la 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. Cuando se procesa una solicitud de autorización de pago 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, preferiblemente de la 14 cartera de usuario, que se usa en la solicitud de autorización de pago generada de los datos de registro almacenados .
Se entenderá que los términos "comercio en linea", "sistema IPSP comercial", "sistema intermediario central confiable" y "sistema procesador de pago de banco adquisidor" se refieren a componentes lógicos. Como tal, cada sistema se puede incluir físicamente separado uno de otro o físicamente conectado a uno o más sistemas. Por ejemplo, en arreglos donde una organización dada aloja el sistema IPSP comercial y el comercio en línea, los componentes se podrán ubicar físicamente en la misma red o aún integrar como parte de un sistema único. Además, donde una organización dada aloja el sistema IPSP comercial y sistema procesador de pago de banco adquisidor, los componentes se podrán ubicar físicamente en la misma red o aún integrar como parte de un sistema único. Aún adicionalmente, la organización podrá alojar el comercio en línea, el sistema IPSP comercial y el sistema de procesamiento de pago de banco adquisidor. Por consiguiente, las modalidades de la invención abarcan arreglos en los cuales las funciones realizadas bajo el papel del IPSP se pueden llevar a cabo por una organización que también es el comercio y/o también el adquisidor.
Debido a que las transacciones, las cuales son autorizadas usando el sistema de la presente invención, aún 15 se procesan por el sistema IPSP comercial, las funciones de IPSP comercial relacionadas con estas transacciones se pueden acceder por el comercio en linea usando una interfaz común para diferentes tipos de transacción. Estos tipos de transacción pueden incluir tanto tipos de transacción para los cuales las solicitudes de autorización de pago se originan via el sistema intermediario confiable como otros tipos de transacción, separadamente autorizados los cuales se pueden procesar por el IPSP en beneficio del comercio sin pasar via el sistema intermediario confiable. Esta interfaz común puede comprender un sitio web en linea seguro.
En al menos un arreglo 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 linea. Además, el método comprende recibir una identidad de comercio en linea del primer sistema comercial en linea, la identidad de comercio en linea se incluye en la solicitud de autorización generada que se genera sobre la base de la identidad de comercio en linea recibida. Por consiguiente, puesto que el sistema intermediario confiable se interconecta con, más bien reemplaza, un sistema IPSP existente del comercio en linea, el identificador de cuenta del comercio en linea es el que se transmite al banco adquisidor. Como un resultado, la relación 16 para tales transacciones es entre el comprador y el comercio en línea, con el beneficio resultante que el comprador es protegido por las reglas del esquema de tarjeta y, en algunas eventualidades, cumplen con cualquier protección del consumidor aplicable. Además, el sistema IPSP comercial puede proporcionar una o más diversas funciones de procesamiento de transacción adicionales, por ejemplo liquidación, manejo de devolución de cargo, manejo de reembolsos, e informe de transacción, en beneficio del sistema comercial en línea. En particular, el sistema IPSP comercial puede proporcionar un comercio en línea con un sitio web en línea seguro para aprobar devoluciones de cargo, iniciar reembolsos y/o ver informes de transacción con relación a las transacciones autorizadas a través del sistema de la presente invención.
Preferiblemente, la etapa de 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 comprende recuperar una dirección de red para el sistema IPSP comercial seleccionado sobre la base del sistema IPSP comercial registrado por el primer comercio en línea, 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. Las 17 direcciones de red son preferiblemente pobladas en una base por comercio en linea, por ejemplo cuando un comercio en linea dado se registra con el sistema intermediario confiable, proporcionando un mecanismo centralizado conveniente para controlar el flujo de solicitudes de autorización de pago. Por consiguiente, el sistema intermediario central confiable preferiblemente proporciona una interfaz de registro para comercios en linea por lo cual un comercio en linea dado puede registrar un sistema IPSP comercial con el cual se asocia el comercio en linea.
En al menos algunos arreglos el sistema intermediario central confiable puede cooperar con una pluralidad de sistemas de autenticación emisores, cada uno siendo responsable de conducir la autenticación para un banco emisor diferente, 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. Esta verificación del usuario se puede realizar usando el método 3-D Secure conocido, y se puede realizar cuando, por ejemplo el usuario añade un instrumento de pago a su cartera de usuario vía la interfaz de registro mencionada antes.
El usuario puede registrarse con el sistema intermediario confiable vía diversos mecanismos diferentes, incluyendo: directo con el sistema intermediario; indirecto 18 vía una tercera parte confiable; y re-dirección vía un servicio de actividad bancaria en línea. Con relación a la tercera alternativa, 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. Después que los datos se transmiten al titular de instrumentos financieros, se habilita al titular de instrumentos financieros para realizar la autenticación con respecto a un sistema de autenticación seleccionado, y se reciben los 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. Además, las modalidades de la invención pueden incluir 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.
De acuerdo con aspectos adicionales de la invención se proporciona un sistema intermediario confiable en comunicación con una pluralidad de sistemas comerciales en linea y una pluralidad de sistemas IPSP comerciales, el 19 sistema intermediario confiable se arregla para conducir las etapas del sistema intermediario confiable antes mencionado. Además, se proporciona un sistema comercial en linea en comunicación con un sistema intermediario confiable y una pluralidad de sistemas IPSP comerciales/ el sistema comercial en linea se arregla para conducir las etapas del sistema comercial en linea antes mencionado. Aún adicionalmente se proporciona un sistema IPSP comercial en comunicación con un sistema intermediario confiable y una pluralidad de sistemas comerciales en linea, el sistema IPSP comercial se arregla para conducir las etapas del sistema IPSP comercial antes mencionado .
Los aspectos de la invención también proporcionan software distribuido entre los diversos sistemas, adecuadamente configurados para realizar el método mencionado antes .
Las características y ventajas adicionales de la invención llegarán a ser evidentes a partir de la siguiente descripción de las modalidades preferidas de la invención, dado por vía de ejemplo solamente, lo cual se hace con referencia a las figuras acompañantes.
Breve Descripción de las Figuras La Figura 1 es un diagrama esquemático que muestra un sistema de pago convencional; 20 La Figura 2 es un diagrama esquemático que muestra un sistema de pago de acuerdo con una modalidad de la invención; La Figura 3 es un diagrama de flujo esquemático que muestra el flujo de datos durante el uso del sistema de pago de la Figura 2 de acuerdo con una modalidad de la invención; La Figura 4 es un ' diagrama de bloque esquemático que muestra componentes del sistema intermediario confiable de la Figura 2 de acuerdo con una modalidad de la invención; y La Figura 5 es un diagrama de sincronización esquemático que muestra el flujo de mensajes entre componentes seleccionados del sistema de pago de la Figura 2 de acuerdo con una modalidad de la invención.
Descripción Detallada de la Invención Como se describió anteriormente, las modalidades de la invención se refieren a un sistema y método de pago, específicamente un sistema y método de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos en beneficio de comercios en línea. El sistema involucra una nueva identidad de transacción, referida en la presente como un sistema intermediario confiable, el cual coopera con las entidades de pago convencionales descritas en la sección de 21 antecedentes con referencia a la Figura 1.
La Figura 2 representa una ilustración esquemática de un sistema de pago 1 de acuerdo con una modalidad de la invención. El sistema intermediario confiable 10 se muestra transmitiendo solicitudes de autorización de pago a cada uno de una pluralidad de diferentes sistemas IPSP comerciales 3a ... 3c. Cada uno de los sistemas de procesamiento comerciales en linea la ... le se asocia con uno de los sistemas IPSP comerciales 3a ... 3c como se indica por la linea de puntos Ll para uno de los comercios en linea le, asi como también se asocia con uno de los bancos adquisidores 5c, como se indica por la linea de puntos L2, de nuevo para el comercio en linea le. Al menos algunos de los sistemas IPSP comerciales 3b, 3c se puede arreglar para transmitir solicitudes de autorización de pago a más de un banco adquisidor: esto refleja el hecho que más de un comercio en línea puede procesar sus pagos vía un sistema IPSP comercial dado; cada comercio tiene una cuenta con un banco adquisidor particular.
Además, cada página web de transmisión de pedido del sitio web del sistema comercial en línea la ... le incluye, como una nueva opción de pago, referido en la presente como "Sistema Seguro de Pago" (SSP) , este identifica el pago vía el sistema intermediario confiable 10. Otras opciones de pago, incluyendo opciones de pago en línea convencionales, también se pueden incluir por lo cual un 22 comprador puede seleccionar una opción de pago la cual no involucra la autorización de pago que se procesa a través del sistema intermediario confiable 10. Tales transacciones separadamente autorizada, por ejemplo, pueden incluir opciones de pago en linea convencionales en las cuales un comprador ingresa sus detalles de pago en el sistema comercial en línea le directamente, o el sistema IPSP comercial le directamente, antes que usar el sistema intermediario confiable 10. Con respecto de tales transacciones, el sistema intermediario confiable 10 se interconecta con, antes que reemplazar, el sistema IPSP comercial en línea 3c, el cual puede ser el sistema IPSP comercial existente del comercio en línea cuando se suscribe al servicio proporcionado por el sistema intermediario confiable 10. Es decir que debido a que los sistemas de pago de acuerdo con las modalidades de la invención involucran la adición del sistema intermediario confiable 10 dentro de un conjunto de entidades de procesamiento existentes y conocidas, los pagos se pueden hacer de acuerdo con los métodos convencionales usando los segundo y tercer tipos de arreglos descritos con referencia a la Figura 1 además, o como una alternativa a, vía el sistema intermediario confiable 10.
El sistema intermediario confiable 10 mantiene los datos en una base de datos DBl correspondiente a los usuarios 23 (compradores) y comercios en linea que se han registrado con el intermediario 10, junto con los datos de transacción. Como se describirá con más detalle posteriormente, la base de datos DB1 mantiene un conjunto de detalles de pago para el usuario en la forma de un conjunto de registros almacenados convenientemente referidos en la presente como un almacén remoto o cartera de usuario; los usuarios pueden añadir detalles de instrumentos de pago (típicamente tarjetas y cuentas) de los cuales se pueden seleccionar para hacer el pago de una transacción, causando que el sistema intermediario confiable actualice los contenidos del almacén remoto del usuario. Puesto que el sistema intermediario confiable 10 mantiene un intervalo de instrumentos de pago disponibles para el usuario, el usuario puede seleccionar un método de pago en una base por transacción. Por consiguiente, los comercios en línea proporcionados se suscriben al sistema intermediario confiable 10, los usuarios solamente tienen que presentar sus detalles de pago respectivos una vez, a una entidad única, removiendo el requerimiento del usuario de proporcionar detalles de pago a comercios en línea individuales cada vez que compren en línea. Esto tiene el beneficio de reducir el riesgo de fraude al que se puede incurrir con relación a los arreglos convencionales de sistemas de pago (tal como aquel mostrado en la Figura 1) .
Debido a que las solicitudes de autorización de 24 transacción las cuales se originan usando el sistema intermediario confiable 10 se pasan y procesan por el sistema IPSP 3c, las diversas funciones de IPSP de procesamiento de transacción adicionales relacionadas con estas transacciones se pueden ingresar por el comercio en linea vía el sistema intermediario confiable 10. El sistema IPSP comercial 3c puede proporcionar una o más de tales funciones de procesamiento de transacción adicionales, por ejemplo liquidación, manejo de devolución de cargo, manejo de reembolsos, e informe de transacción, en beneficio del sistema comercial en linea le. El sistema IPSP comercial 3c preferiblemente provee al comercio en linea con un sitio web en linea seguro para aprobar devoluciones de cargo, iniciar reembolsos y/o ver informes de transacción relacionados con las transacciones autorizadas a través del sistema intermediario confiable 10.
Además, puesto que las solicitudes de autorización de transacción las cuales se originan usando el sistema intermediario confiable 10 se pasan y procesan por el sistema IPSP 3c, las funciones del IPSP relacionadas con estas transacciones se pueden ingresar por el comercio en linea usando una interfaz de sistema IPSP la cual es común para diferentes tipos de transacción, incluyendo tanto tipos de transacción autorizados vía el sistema intermediario confiable 10 como otros tipos de transacción, separadamente 25 autorizadas, los cuales se pueden procesar por el IPSP en beneficio del comercio sin pasar vía el sistema intermediario confiable 10. Tales transacciones separadamente autorizadas, por ejemplo, pueden incluir transacciones para las cuales un comprador ingresa su detalles de pago en el sistema comercial en línea le directamente, o el sistema IPSP comercial 3c directamente, para uso en autorizaciones de pago conducidas por el sistema IPSP comercial le.
Aún adicionalmente, el identificador de cuenta de internet de comercio en linea es el que se transmite al banco adquisidor 5c por el sistema IPSP comercial 3c como parte de la solicitud de autorización de pago. Esto tiene el beneficio de asegurar que el comprador sea protegido por las reglas del esquema de tarjeta y, en algunas eventualidades, cumplir con cualquier protección al consumidor aplicable; además cada transacción se puede identificar en una base por comercio en línea en los estados de cuenta de la tarjeta del usuario.
Como se puede ver de la Figura 2, específicamente la línea de puntos L3, el sistema intermediario confiable 10 se conecta al sistema de banco emisor 9a (mientras que solamente se muestra una conexión, se entenderá que puede existir una conexión entre el sistema intermediario confiable 10 y cualquier número de sistemas de banco emisor) . Esta conexión facilita la verificación del titular _ de la tarjeta (comprador) usando el mecanismo de autenticación 3-D Secure 26 bien conocido. El protocolo para 3-D Secure es documentado en la solicitud de patente de Estados Unidos 10/156,271, publicada bajo el número de publicación US2002/0194138 a nombre de Visa International service Association, el contenido de la cual se incorpora para referencia en la presente en su totalidad. El protocolo usa mensajes (típicamente mensajes XML) enviados sobre las conexiones de Capa de Conexión Segura (SSL) , como es documentado en la publicación de patente mencionada antes como el Servicio de Autenticación de Pagador (PAS) . Este servicio se puede emplear cuando el sistema intermediario confiable 10 determina que una transacción solicitada dada corresponde al nivel de riesgo predeterminado, tal como puede ser el caso para transacciones que involucran envió al extranjero de mercancías de alto valor. Los medios por los cuales la evaluación de riesgo se realiza y en efecto un nivel de riesgo determinado para una transacción dada se describe con más detalle posteriormente.
El sistema de esquema de tarjeta 7 se conecta comunicativamente al sistema intermediario confiable 10 como se muestra esquemáticamente por la línea de puntos L4; esto indica que el sistema intermediario confiable 10 se ha suscrito a un servicio de actualización de cuentas (no etiquetado en la Figura 2, pero descrito con referencia a la Figura 4 posterior como parte 415d) proporcionado por el 27 sistema de esquema de tarjeta 7 y por lo tanto recibe información de tarjeta actualizada, por ejemplo cuando una tarjeta se pierde, es robada o ha vencido, y por consiguiente se ha reemitido al usuario. Un ejemplo de tal servicio es el servicio Actualizador de Cuentas Visa (VAU) , mientras que otro es el Actualizador de Facturación Automática Mastercard. En un arreglo la interfaz para el servicio de actualización de cuentas proporcionado por el sistema de esquema de tarjeta 7 es orientado por lote: el sistema intermediario confiable 10 presenta una solicitud o solicitudes al sistema de esquema de tarjeta 7, la solicitud incluye detalles de ciertos usuarios registrados con el sistema 10. Una interfaz en lote típicamente se usa (por ejemplo, Protocolo de Transferencia Segura de Archivos (SFTP) o Connect : DirecttTM) ) para enviar los archivos de solicitud al servicio de actualización de cuentas, el cual es responsable de otorgar los detalles de las tarjetas reemitidas. Después de un intervalo el sistema intermediario confiable 10 ingresa al servicio de actualización de cuenta y colecta los archivos de respuesta, después actualiza los instrumentos de pago localmente para los suscriptores relevantes para el sistema SSP. Alternativamente la interfaz podrá estar basada en mensajes, de modo que los Números de Cuenta Principales individuales se pueden verificar o actualizar en tiempo real. Como una alternativa a enviar la solicitud directamente al sistema de 28 esquema de tarjeta 7, el sistema intermediario confiable 10 podrá emular la operación de un envío de solicitud de comercio en línea a los sistemas de banco adquisidor conocidos 5a ... 5c, para transmisión subsecuente al sistema de esquema de tarjeta 7.
Con referencia ahora a la Figura 3, ahora se describirá la operación del sistema de pago 1 de acuerdo con una modalidad de la invención. En la etapa S301 el usuario completa su experiencia de compra con el sistema comercial en línea del comercio en línea C's, inicia el pago usando el sistema comercial en línea, y procede al pago virtual, de acuerdo con los métodos convencionales disponibles a través de los paquetes de software de pago y carrito de compras comúnmente disponibles tal como son conocidos por la persona experta. El usuario selecciona "Sistema Seguro para Pago" (SSP) como una opción de pago (etapa S301), causando que el sistema comercial en línea le transmita un mensaje de solicitud de autorización de pago originado al sistema intermediario confiable 10 (etapa S303) ; el mensaje de solicitud originado comprende al menos una cantidad del pago para las mercancías seleccionadas, el identificador de cuenta de comercio en línea y un identificador para el pedido. El sistema intermediario confiable 10 luego transmite una URL de inicio de sesión al usuario (etapa S305) , incitando al usuario a iniciar sesión, o, si es su primera vez que 29 selecciona SSP como una opción de pago, registrarse con el sistema intermediario confiable 10. Asumiendo los propósitos de este ejemplo que el usuario previamente se ha registrado con el servicio, el usuario ingresa sus credencias de inicio de sesión (por ejemplo, nombre de usuario, contraseña, u otros detalles de autenticación, dependientes del mecanismo de autenticación utilizado por el sistema intermediario confiable 10 - etapa S307) .
El sistema intermediario confiable 10 luego realiza una consulta con base en los detalles de identificación y credenciales del usuario (etapa S309) , recuperando los detalles del almacén remoto del usuario de la base de datos DB1, y presentando lo mismo al usuario para su selección de método de pago (etapa S310) . En la selección del método de pago deseado de las opciones proporcionadas de acuerdo con los detalles recuperados del almacén remoto del usuario el sistema intermediario confiable 10 envía un mensaje de solicitud de autorización de pago al sistema IPSP del comercio en línea 3c, el mensaje de solicitud de autorización de pago comprende los detalles del instrumento de pago seleccionado, la cantidad de pago requerida y el identificador de comercio en línea (etapa S311) . El sistema IPSP comercial 3c envía una solicitud de autorización de pago adicional al banco adquisidor relevante 5c (etapa S313) , fomentando la autorización (o de otra manera) por métodos 30 convencionales (etapa S315) y la transmisión de un mensaje de respuesta del banco adquisidor 5c al sistema IPSP comercial 3c (etapa S317) . Asumiendo que la respuesta comprende la confirmación del pago que se ha autorizado, en la etapa S319, el sistema IPSP comercial 3c envía un mensaje de notificación de éxito de pago al sistema intermediario confiable 10. Este mensaje de notificación de éxito de pago comprende una referencia para la autorización del esquema de tarjeta y un identificador de transacción para la transacción del esquema de tarjeta.
Después el sistema intermediario confiable 10 envía un mensaje de confirmación de éxito de pago al sistema comercial en línea le (etapa S321) , lo cual fomenta al sistema comercial en línea a confirmar el estado del pedido al usuario (etapa S323) .
Se apreciará de lo anterior que los sistemas comerciales en línea convencionales (incluyendo su sistema IPSP comercial) requieren la modificación para incluir "Sistema Seguro para Pago" (SSP) como una opción de pago y en efecto para interconectarse con el sistema intermediario confiable 10. Por consiguiente, el sistema IPSP comercial expone un servicio de autorización de pago al sistema intermediario confiable 10 que permite el pago y liquidación por instrumentos de pago (típicamente tarjetas y cuentas bancarias) . Además se apreciará que debido a que el sistema 31 intermediario confiable 10 se integra con muchos sistemas IPSP comerciales, comprende por consiguiente una pluralidad de protocolos y formatos de ínterfaz, cada uno correspondiente a un sistema IPSP comercial respectivo. Además, cada sistema comercial en línea se configura con componentes de software de integración, por ejemplo en la forma de plugins, lo cual habilita al comercio en línea a integrarse con el sistema intermediario confiable 10 para el propósito de iniciar una transacción de pago usando SSP como un método de pago.
Los detalles de las capacidades de procesamiento y configuración del sistema intermediario confiable 10 ahora serán descritos con referencia a la Figura 4. El sistema intermediario confiable 10 comprende componentes de procesamiento de conectividad y presentación, los cuales se configuran para transmitir y manejar varios datos específicos del comercio en línea y específicos del usuario; estos componentes de procesamiento serán explicados con más detalle posteriormente, pero en la revisión general comprenden lo siguiente: Datos y componentes de registro del usuario Cuando un usuario desea registrarse con el sistema intermediario confiable 10, se requiere que se complete un proceso de registro de cuenta que permite al usuario crear 32 una cuenta con el servicio SSP. La cuenta se requiere que sea poblada con datos apropiados que se pueden usar para hacer pagos desde el servicio SSP de un sistema comercial en linea que ofrece el servicio.
Una vez registrado, cada usuario tiene un conjunto de registros asociados con este, el cual almacena los detalles de las cuentas a las cuales desean cargar una suma cuando efectúen una transacción financiera. Esta podrá ser una cuenta de banco, una tarjeta de pago u otra cuenta tal como cualquier instrumento de pago al que se pueda dar una referencia de cuenta única. El sistema intermediario confiable 10 comprende componentes de presentación 404 que habilitan al usuario a seleccionar y añadir/remover de la lista de instrumentos de pago. Además el usuario tiene entradas de libreta de direcciones, las cuales retienen detalles de envío; los componentes de presentación 404 habilitar al usuario a modificar los detalles de envío. Cada usuario tiene un perfil, el cual comprende datos de identificación y demográficos para el usuario y se pueden modificar vía los componentes de presentación 404, mientras que los datos de transacción de usuario se pueden visualizar para revisión por el usuario. Como se muestra en la Figura 4 y explicado con más detalle posteriormente, el sistema intermediario confiable 10 se puede implementar como un servidor web, en este caso los componentes de presentación 33 404 interoperan con el buscador del usuario para permitir la selección y modificación de los datos de usuario en la manera apenas descrita. Sin embargo, el registro del usuario con el sistema intermediario confiable 10 se puede realizar vía cualquier interfaz adecuada alternativa.
El registro se puede efectuar vía un número de canales : • Registro vía sitio SSP - el usuario se registra en el sitio web del sistema intermediario confiable 10 y se presenta con una página de registro diseñada para capturar los detalles del instrumento de pago preferido e identidad del usuario • Redirección desde otro sistema - Si el usuario está dentro del sistema de pedidos del comercio en linea y desea efectuar el pago usando la opción SSP necesitará registrar si no lo ha hecho. El usuario es redirigido a las pantallas de registro asociadas con el sistema intermediario confiable 10 y luego redirigido de nuevo al sistema del comercio en linea.
• Registro vía un banco en linea - asumiendo que el sistema intermediario confiable 10 comprende la funcionalidad de integración necesaria, el usuario puede registrarse para el servicio SSP dentro del servicio de cuenta en linea del banco. 34 Componentes de autenticación del usuario La autenticación de un usuario en el sistema intermediario confiable 10 para las transacciones de pago se puede realizar de acuerdo con cualquiera de las 3 categorías conocidas listadas posteriormente: Factor de autenticación 1 - Algunas veces el usuario conoce (por ejemplo, un nombre de usuario y contraseña, frase que contiene la contraseña, un número de identificación personal (PIN) ) Factor de autenticación 2 - Como el factor de autenticación 1, más, algunas veces el usuario tiene (por ejemplo, tarjeta ID, token de seguridad, token de software, teléfono, o teléfono celular) Factor de autenticación 3 - Como el factor de autenticación 2, más, algunas veces el usuario es o hace (por ejemplo, patrón retinal o de huella, secuencia de ADN (son definiciones clasificadas de lo que es suficiente) , reconocimiento de voz o firma, señales bioeléctricas únicas, u otro identificador biométrico) .
Un ejemplo de un mecanismo para habilitar la autenticación es el servicio 3-D Secure mencionado antes - facilitado por el sistema intermediario confiable 10, el banco emisor sugiere al comprador una contraseña que sea conocida solamente por el banco y el comprador. Puesto que el comercio no conoce esta contraseña y no es responsable de capturarla, se puede usar 35 por el banco emisor como evidencia que el comprador en efecto es su titular de la tarjeta.
En una modalidad el sistema intermediario confiable 10 implementa el proceso de autenticación. Alternativamente el usuario puede iniciar cesión vía sus detalles de actividades bancarias en linea en este caso el usuario podria iniciar sesión en su cuenta bancaria en linea, en donde el software del sistema bancario podria redirigir al usuario de nuevo al sistema intermediario confiable 10. Como una alternativa adicional, la autenticación podrá involucrar una entidad de identificación de cuenta, la cual, basada en la entrada especifica del usuario, podrá actuar como un intermediario y cooperar con el sistema intermediario confiable 10 para efectuar la identificación de la cuenta del usuario en beneficio del usuario.
Almacén de datos de comercio en linea: El sistema intermediario confiable 10 almacena los datos de registro y perfil de comercio en linea. Estos datos incluyen un identificador de cuenta de internet de comercio en linea junto con un identificador de red y de transacción del sistema IPSP comercial 3c con el cual el sistema comercial en linea se registra. Estos datos son retenidos para habilitar al sistema intermediario confiable 10 para comunicarse con el sistema IPSP comercial 3c en beneficio del 36 sistema comercial en linea, y son referidos colectivamente como datos de transmisión de sistema IPSP comercial, o simplemente datos de transmisión. Además el sistema intermediario confiable 10 comprende un servicio de autorización de pago a través del cual el sistema intermediario confiable 10 efectúa los pagos en beneficio del comercio en linea. Además, debido a que el sistema intermediario confiable 10 se integra con muchos sistemas IPSP comerciales éste comprende una pluralidad de protocolos y formatos de interfaz. Los detalles de los protocolos y formatos relevantes para cada sistema IPSP comercial son retenidos en el almacén de datos de comercio en linea. Por consiguiente, los datos de transmisión mencionados antes comprenden un mapeo de una solicitud de autorización de pago que emana de un sistema comercial en linea dado a un identificador de IPSP, una dirección de red y/o protocolos de red que habilitan las solicitudes de autorización de pago para ser enrutadas al sistema IPSP comercial relevante.
Por lo tanto se apreciará que el registro* de cualquier comercio dado que ofrece el servicio SSP involucra el comercio que especifica al sistema IPSP comercial cual suscribir. Convenientemente, el intermediario confiable 10 puede retener un conjunto de registros correspondientes a sistemas IPSP comerciales activos: cada conjunto de registros puede comprender identificador de red y ' protocolos de 37 comunicaciones requeridos para almacenamiento en la base de datos DB1 por el intermediario confiable 10. Por consiguiente, durante el registro con el SSP el comercio en linea dado puede seleccionar, por ejemplo, vía una lista desplegable coordinada por los componentes de presentación 404 del intermediario confiable 10, el sistema IPSP comercial al cual el comercio en linea se ha suscrito; los datos de transmisión correspondientes (o un enlace a estos) luego se pueden almacenar en conjunto con los registros de comercio retenidos en la base de datos DB1. Por consiguiente, siempre que el comercio en linea dado especifica su sistema IPSP comercial correspondiente en la manera apenas descrita, entonces en respuesta a la recepción de una solicitud de autorización de pago del sistema comercial, el intermediario confiable 10 puede realizar una consulta adecuada de la base de datos y recuperar el identificador de red, requerimientos de protocolo, etc. del sistema IPSP comercial correspondiente.
Adaptador de servicios de Interfaz de Programación de Aplicación (API) El sistema intermediario confiable 10 comprende un Adaptador de Servicios API, el cual habilita la conectividad entre el sistema intermediario confiable 10 y la infraestructura de mensajería del sistema de pago 1. El 38 adaptador se configura para manejar el cumplimiento de las solicitudes del sistema intermediario confiable 10 a servicios externos, tales como autorizaciones de pago al sistema IPSP comercial 3c y para exponer un conjunto de los servicios del sistema intermediario confiable 10 que se podrá usar por funciones externas tal como el sistema IPSP comercial 3c.
Datos y componentes específicos de la transacción: El sistema intermediario confiable 10 almacena datos de transacción tales como autorizaciones de pago y estados de cuenta que se manejan por el sistema intermediario confiable 10. Además, el sistema intermediario confiable 10 puede almacenar datos de auditoria asociados con usuarios y actividad en linea de comercio en linea asi como también actividad de sistema general.
Servicios de Mensajería El sistema intermediario confiable 10 se configura con agentes de correo electrónico, los cuales componen y transmiten correos electrónicos para los propósitos de autenticación de dirección de correo electrónico y confirmaciones de pedido de compra y activación de usuario.
Como se mencionó anteriormente el sistema intermediario confiable 10 preferiblemente se incluye como un 39 servidor de aplicación web, por ejemplo como un servidor de aplicación compatible J2EE 401 el cual maneja y proporciona acceso a la lógica de negocios común de la plataforma, y un servidor web y motor servlet J2EE 403, el cual actúa como el punto de entrada para las solicitudes externas de HTTP al sistema intermediario confiable 10 desde comercios en linea y de buscadores de usuarios.
El servidor web y motor servlet 403 comprenden componentes de presentación, los cuales exponen envoltorios de API o APIs de pago basadas en servicios web a los sistemas comerciales en linea. Además, el servidor web y motor servlet 403 comprenden componentes de procesamiento de presentación 404 los cuales se configuran para generar y manejar la interfaz para el usuario, por ejemplo, cuando el usuario selecciona un método de pago en la manera descrita anteriormente .
El Servidor de Aplicación J2EE 401 maneja toda la lógica de negocios para las aplicaciones y plataforma web. La lógica de negocios comprende componentes de software funcionales 411a ... 411e, los cuales se pueden implementar, por ejemplo, como EJBs (Java Beans Empresariales) de Sesión. Estos grupos funcionales incluyen, por ejemplo, módulos de procesamiento de correo electrónico, módulos de validación de dirección, y módulos de servicio de seguridad y contra fraude; además el servidor 401 comprende objetos 40 implementados, por ejemplo, como objetos Java específicos de EJB 3.0 411f ... 41lh que proporcionan acceso a datos persistentes y estáticos almacenados en la DB1 tales como datos de usuario, datos de auditoria y datos de transacción descritos anteriormente. El sistema intermediario confiable 10 comprende servicios web en la forma de envoltorios que exponen los EJBs de Sesión a otros elementos del sistema de pago 1. Más específicamente, los componentes de software funcionales 411a ... 411e se interpolan con habilitadores de servicio externos 405 tales como servicios de validación de dirección 415a, aplicaciones de correo electrónico (incluyendo acceso a un servidor de correo electrónico) 415b, servicios 3-D Secure 415c, servicios de actualización de cuenta 415d, y servicios contra fraudes 415e, entre otros. Los componentes del servidor de aplicación 401 411a ... 411e se comunican con los componentes de aplicación 415a ... 415e vía un conjunto de APIs, referidos genéricamente, tal como con relación a las partes 413a ... 413e. Cuando se implementar como un servidor web, los datos entre los elementos del sistema de pago 1 (es decir, aquellos mostrados en las Figuras 2 y 3) y el sistema intermediario confiable 10 se transmiten usando un mecanismo seguro, por ejemplo vía el HTTP sobre el protocolo de Capa de Conexión Segura (HTTPS) .
En el caso del componente funcional de servicio 3-D Secure 411c, este componente usa, o coopera con, reglas 41 basadas en el riesgo las cuales son invocadas para determinar si o no el componente se. deberá involucrar en las interacciones entre el usuario y el intermediario confiable 10. Las reglas típicamente se configuran bajo control de los servicios contra fraude 415e, y por ejemplo, pueden especificar que el método 3-D Secure se deberá invocar cuando un usuario registra un instrumento de pago con el servicio SSP (para asegurar que el usuario es el titular de la tarjeta legítimo) ; para la primera transacción que un comprador hace; para transacciones que exceden un cierto valor, para transacciones que involucran el envío de mercancías fuera del territorio doméstico del comprador) ; y para ciertos tipos de mercancías y/o servicios. Otros eventos que pueden activar el servicio 3-D Secure, incluyendo la invocación del servicio para todas las transacciones, serán evidentes para un experto en el arte.
Regresando al componente funcional de actualización de cuenta (AU) 4lid y servicio correspondiente 15d proporcionado por el sistema de esquema de tarjeta 7, el componente de AU 411d comprende rutinas para revisar rutinariamente las fechas de vencimiento de los instrumentos de pago almacenados en las carteras de usuarios individuales en la base de datos DB1, y presentar solicitudes al sistema de esquema de tarjeta 7 con detalles de usuarios cuyos instrumentos de pago vencen dentro de una ventana de tiempo 42 especificada. El componente de AU 4lid posteriormente accede al servicio de actualización de cuenta 15d y colecta un archivo de respuesta generado, y actualiza los instrumentos de pago en las carteras de usuario relevantes sobre la base del contenido del archivo de respuesta.
Las etapas de procesamiento descritas anteriormente con referencia a la Figura 3, específicamente las etapas realizadas en particular por el sistema intermediario confiable 10 cuando se interconecta con las diversas entidades de pago, ahora serán descritas con más detalle. Regresando a la Figura 5, en la etapa S5.1, el usuario selecciona el servicio de pago SSP como el método de pago y presenta su selección al sitio web de comercio en línea. Esto activa una solicitud del sistema comercial en línea, específicamente la recuperación por el sistema comercial en línea de la URL correspondiente para una página de inicio de sesión del sistema intermediario confiable 10, y posteriormente el envío de una orden de clave más campos de comercio en línea que incluyen una URL de retorno (etapa S5.3) y la creación de una sesión segura. Habiendo recibido la URL de inicio de sesión del sistema intermediario confiable 10, el sistema comercial en línea visualiza la página de inicio se sesión al usuario (etapa S5.5). En un arreglo la página de inicio de sesión se implementa como una iFrame, la cual habilita al usuario a comunicarse 43 directamente con el sistema intermediario confiable 10 el cual permanece dentro del ambiente en linea del comercio en linea. El usuario ingresa sus detalles de inicio de sesión (etapa S5.7), y es autenticado de acuerdo con uno de los mecanismos de autenticación descritos anteriormente (etapa S5.9), si la autenticación es exitosa, el servidor web y motor servlet 403 envían el contenido de datos del almacén remoto del usuario al iFrame para visualización y selección en este (etapa S5.ll). Una vez que el usuario ha seleccionado su método de pago de las opciones dentro de los contenidos de almacén remoto descargados, el usuario presenta su opción seleccionada (etapa S5.13) al servidor web y motor servlet 403, resultando en una página de confirmación que se transmite al iFrame (etapa S5.15).
Una vez que el usuario ha confirmado la selección de pago y presentado la misma (etapa S5.17), el servidor web y motor servlet 403 envían los detalles de pago al sistema IPSP del comercio en línea 3c (etapa S5.19) vía un servicio de autorización de pago a través del cual el sistema intermediario confiable 10 efectúa los pagos en beneficio del comercio en línea. Bajo ciertas circunstancias el servidor de aplicación 401 invoca un proceso 3-D Secure respondedor a la recepción de la selección de pago en la etapa S5.17. Por ejemplo, el servidor de aplicación 401 puede invocar el componente 3-D Secure 411c, el cual, sobre la base del 44 contenido del mensaje de solicitud de pago, determina si o no el usuario será verificado por el banco emisor correspondiente antes de continuar con el procesamiento de la transacción. En el caso que el componente 3-D Secure 411c determine que la transacción presenta un nivel de riesgo predeterminado (sobre la base de las reglas accesible al componente 411c), el componente 3-D Secure 411c configura una comunicación segura entre el usuario y un sistema de autenticación de banco emisor de 3-D Secure correspondiente 415c. Por ejemplo, una transacción usando Verified by Visa/SecureCode iniciará una redirección al sitio web del banco emisor, o iniciará la carga de una sesión de marco en linea, para autorizar la transacción.
Asumiendo que el usuario es verificado, o en caso donde la verificación se considera innecesaria para la transacción en cuestión, la etapa S5.19 involucra crear una solicitud de autorización para recepción por las APIs de pago 406, convertir la solicitud de autorización de pago en el formato API de la API del comercio en linea y transmitir la solicitud formateada al sistema IPSP comercial 3c. Una solicitud de estado de cuenta también se transmite a las APIs de pago 406, las cuales realizan la conversión de la solicitud de estado de cuenta en el formato API de la API del comercio en linea y transmiten la misma al sistema IPSP comercial 3c. Se apreciará que la comunicación se puede 45 efectuar por implementaciones de mensaje ya sea dual o único. Estas acciones de formateo y transmisión se registran en el almacén de datos de transacción retenido por el sistema intermediario confiable 10 correspondiente al sistema comercial en línea.
En la notificación de la autorización de solicitud de pago (etapa S5.21), el servidor web y motor servlet 403 transmiten una URL de comercio en línea de retorno al iFrame (etapa S5.23), junto con la notificación de autorización exitosa, causando que el iFrame se vacíe, recargue con código Javascript del sistema comercial en línea (etapa S5.25), y por consiguiente remueva el iFrame y regrese al usuario al sitio web del sistema comercial en línea. Finalmente, el sitio web del sistema comercial en línea exhibe una página web de pedido exitoso en la etapa S5.27.
¦En paralelo con las etapas S5.13-S5.19, el servidor de aplicación 401 puede iniciar la actividad del usuario y enviar la misma al almacén de datos de auditoria, mientras envía la información de evento y sistema correspondiente a un sistema de notificación de fraude por terceras partes (se representa por uno de los habilitadores de servicio comunes 415e mostrados en la Figura 4) . El sistema de notificación de fraude comprende, pero no se limita a, un motor de riesgo de fraude, el cual realiza el análisis del mismo para generar un registro de riesgo y una acción recomendada para la 46 transacción; los sistemas de notificación de fraude adecuados tal como aquel proporcionado por RSA™ en su paquete de prevención de fraude son conocidos y no serán descritos con más detalle en la presente. El registro de riesgo y acción se almacenan en la base de datos DB1, en conjunto con los otros detalles de transacción para el comercio en línea y el usuario.
Las modalidades anteriores se entenderán como ejemplos ilustrativos de la invención. Se contemplan modalidades adicionales de la invención. Por ejemplo, mientras que en los ejemplos anteriores el sistema intermediario confiable 10 se describe recibiendo solicitud de pago de sistemas comerciales en línea, el intermediario 10 adicionalmente o alternativamente podrá recibir solicitudes de pago de un sistema IPSP comercial en el tercer tipo de arreglo descrito en la sección de antecedentes en casos donde tales sistemas IPSP comerciales se han modificado para ofrecer SSP como una opción de pago.
Además, mientras que las modalidades preferidas hacen uso de la tecnología web . iFrame para hacer que el usuario navegue a diferentes sitios web, se apreciará que la redirección web estándar se puede emplear en su lugar. En tales arreglos alternativos el buscador del usuario navegará lejos de y de nuevo en el sitio web de SSP, dependiendo de la entidad (o más bien la URL correspondiente a este) con la 47 cual el buscador del usuario está comunicado en cualquier punto temporal. Por ejemplo, durante la autenticación y/o selección de cuenta por el usuario, el buscador del usuario se puede redirigir por el sitio web de SSP a un sitio web proporcionado por, o en beneficio de, banco emisor del usuario, y una vez que la autenticación del usuario y/o selección de cuenta se realiza, el buscador del usuario se puede redirigir por el sitio web del banco emisor de nuevo al sitio web de SSP.
En las modalidades anteriores el sistema intermediario confiable 10 se describe almacenando detalles de envío en el conjunto de registros de usuario: a este grado el sistema intermediario confiable 10 se puede ver proporcionando parte de la funcionalidad asociada con una herramienta de verificación: los campos relevantes almacenados en la base de datos DB1 podrán estar disponibles a través de la interfaz para habilitar los sistemas comerciales para referenciar los datos durante el proceso de verificación y poblar los campos apropiadamente. Sin embargo, se entenderá que este es un aspecto opcional del intermediario 10. En efecto, la funcionalidad de verificación se podrá proporcionar por el sistema comercial en línea le, en este caso el sistema intermediario confiable 10 simplemente podría realizar el papel de una herramienta de pago, y la base de datos DB1 entonces podría almacenar pocos 48 artículos de información específica del usuario.
En lo anterior, el término "sistema", cuando se aplica a entidades tales como el sistema comercial, el sistema IPSP comercial, el sistema intermediario confiable y otras entidades, se deberá entender que significa una función de procesamiento de datos, proporcionado en uno o más sitios físicos, conectados a otras funciones de procesamiento de datos vía enlaces de comunicaciones de datos. Cada función se puede proporcionar por un nodo de procesamiento de datos único, por ejemplo una computadora servidora, o un conjunto de nodos de procesamiento de datos que proporcionan el respaldo en caso de fallos entre si, tal como un agrupamiento de computadoras servidoras, y/o un conjunto de nodos de procesamiento de datos interconectados que proporcionan diferentes sub-funciones modulares con respecto a otros miembros del conjunto, por ejemplo un conjunto de interconexión de diferentes computadoras servidoras.
Como se apreciará de lo anterior, las comunicaciones entre las diversas entidades que comprenden el sistema de pago 1 preferiblemente proceden vía una red de comunicaciones de datos tal como la Internet. Cada una de las entidades del sistema de pago 1 (el banco emisor; el intermediario confiable; el procesador de banco adquisidor; los sistemas IPSP comerciales; y los sistemas comerciales en línea) es identificable vía un identificador de red tal como 49 una dirección de Protocolo de Internet (IP) u otro identificador adecuado.
Por consiguiente, la red de comunicaciones puede comprender una red que comprende una o más tecnologías, es decir red de comunicación híbrida; por ejemplo, la red puede comprender la Internet en conjunto con la Red Telefónica Pública Conmutada (PSTN) y/o una red de comunicación móvil capaz de soportar, por ejemplo, uno o más de los siguientes protocolos: GSM (Sistema Global para Comunicaciones Móviles), WCDMA (Acceso Múltiple por División de Códigos de Banda Ancha) , GPRS (Servicio General de Radiocomunicaciones por Paquetes) . Además o en lugar de la red de comunicación móvil, una red de área local tal como una red de área Local Inalámbrica (WLAN) o BlueTooth® (BT) y/u otras tecnologías tal como WiMax se pueden usar para portar parte de la solicitud de autorización de pago y mensajes de respuesta. En esta forma, los usuarios pueden interactuar con los sistemas comerciales en línea usando dispositivos portátiles remotos. La red de comunicaciones de datos se puede arreglar para soportar acceso genérico a Internet usando cualquiera de los métodos de transporte. Además, o como una alternativa, de enviar mensajes de confirmación como mensajes de correo electrónico, los mensajes de confirmación de pago se pueden transferir como mensajes SMS (Servicio de Mensajes Cortos), mensajes MMS (Servicio de Multimedia), páginas de Protocolo 50 de Aplicación Inalámbrica (WAP) , páginas de Internet, páginas HTML (Lenguaje de Marcación de Hipertexto) , páginas XHTML (HTML extendido), o datagramas de IP (Protocolo de Internet).
Se entenderá que cualquier característica descrita con relación a cualquier modalidad se puede usar sola, o en combinación con otras características descritas, y también se puede usar en combinación con una o más características de cualquiera de las otras modalidades, o cualquier combinación de cualquiera de las otras modalidades. Además, equivalentes y modificaciones no descritas anteriormente también se pueden emplear sin apartarse del alcance de la invención, el cual se define en las reivindicaciones acompañantes.

Claims (26)

51 REIVINDICACIONES
1. Un método de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos en beneficio de comercios en linea, 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 linea, cada uno de los comercios en linea tiene una identidad de comercio en linea, y cada uno de los comercios en linea 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 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 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 caracterizado porque el método comprende: 52 recibir desde un primer sistema comercial en linea, responsable de originar solicitudes de autorización de pago para un primer comercio en linea, 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 linea; 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 linea, asociada con el primer comercio en linea, 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 linea; y 53 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 linea 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 linea.
3. Un método de conformidad con la reivindicación 1 o reivindicación 2, caracterizado porque el primer comercio en linea es un titular de cuenta de comercio en linea 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 linea del primer sistema comercial en linea, la identidad de comercio en linea incluida en la solicitud de autorización generada se genera sobre la base de la identidad de comercio en linea 54 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 55 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 56 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 57 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 linea a través de la cual la transacción de pago se conduce, en beneficio del primer comercio en linea.
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 58 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 59 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 porgue 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 60 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 linea en comunicación con un sistema intermediario confiable y una pluralidad de sistemas IPSP comerciales, caracterizado porque el sistema comercial en linea 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 61 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 linea y con una pluralidad de comercios en linea, 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 linea, 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 linea, la solicitud de autorización de pago recibida se inicia como un resultado de un titular de instrumentos financieros que conduce un pedido via el primer sistema comercial en linea 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: 62 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 linea, asociada con el primer comercio en linea, 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 linea; 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 linea se asocia. 63 RESUMEN DE LA INVENCIÓN Las modalidades de la invención proporcionan un método de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos en beneficio de comercios en linea, 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 linea, cada uno de los comercios en linea tiene una identidad de comercio en linea. El método se conduce por un sistema intermediario central confiable el cual se arregla para 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 sistema IPSP comercial 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, y 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. 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 64 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 linea; 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 linea, 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 linea; y 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. Las modalidades de la invención habilitan a un usuario para seleccionar un método de pago en una base por transacción, mientras remueve el requerimiento que el usuario proporcione 65 detalles del pago a sistemas comerciales en linea individuales o a sus sistemas IPSP comerciales. Por consiguiente, siempre que los comercios en linea, o sus IPSP comerciales, se suscriban a un servicio arreglado para realizar el método, los usuarios solamente tienen que presentan sus detalles de pago respectivos, preferiblemente solo una vez, a una entidad confiable separada.
MX2011007256A 2009-01-06 2010-01-06 Sistema de pago. MX2011007256A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0900150A GB2466676A (en) 2009-01-06 2009-01-06 A method of processing payment authorisation requests
US12/416,836 US8706577B2 (en) 2009-01-06 2009-04-01 Payment system
PCT/EP2010/050079 WO2010079182A1 (en) 2009-01-06 2010-01-06 Payment system

Publications (1)

Publication Number Publication Date
MX2011007256A true MX2011007256A (es) 2012-01-20

Family

ID=40379226

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2011007256A MX2011007256A (es) 2009-01-06 2010-01-06 Sistema de pago.

Country Status (10)

Country Link
US (2) US8706577B2 (es)
EP (1) EP2386096A1 (es)
KR (1) KR101658684B1 (es)
CN (1) CN102341817B (es)
AU (1) AU2010204316B2 (es)
CA (1) CA2748913C (es)
GB (1) GB2466676A (es)
HK (1) HK1166871A1 (es)
MX (1) MX2011007256A (es)
WO (1) WO2010079182A1 (es)

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9715691B2 (en) * 2001-01-16 2017-07-25 Gtj Ventures, Llc Apparatus and method for providing transaction history information, account history information, and/or charge-back information
US7529698B2 (en) * 2001-01-16 2009-05-05 Raymond Anthony Joao Apparatus and method for providing transaction history information, account history information, and/or charge-back information
US9117206B2 (en) * 2001-01-16 2015-08-25 Gtj Ventures, Llc Apparatus and method for providing transaction history information, account history information, and/or charge-back information
US8985442B1 (en) * 2011-07-18 2015-03-24 Tiger T G Zhou One-touch payment using haptic control via a messaging and calling multimedia system on mobile device and wearable device, currency token interface, point of sale device, and electronic payment card
US7774402B2 (en) 2005-06-29 2010-08-10 Visa U.S.A. Adaptive gateway for switching transactions and data on unreliable networks using context-based rules
US9524496B2 (en) * 2007-03-19 2016-12-20 Hugo Olliphant Micro payments
GB2466810A (en) 2009-01-08 2010-07-14 Visa Europe Ltd Processing payment authorisation requests
US9131007B2 (en) * 2009-05-19 2015-09-08 Vitrual World Computing, Inc. System and method for dynamically transcoding data requests
US9064246B1 (en) * 2009-10-13 2015-06-23 Sprint Communications Company L.P. Payment service and platform authentication integration
US8543508B2 (en) 2010-07-09 2013-09-24 Visa International Service Association Gateway abstraction layer
GB2483633A (en) * 2010-09-06 2012-03-21 Mobank Ltd Transaction processing using a proxy
US9953309B2 (en) 2010-09-21 2018-04-24 Visa International Service Association Third party integrated security system
US8639778B2 (en) * 2011-02-01 2014-01-28 Ebay Inc. Commerce applications: data handshake between an on-line service and a third-party partner
US8924297B2 (en) * 2011-02-25 2014-12-30 Visa International Service Association Direct connection systems and methods
US8593659B2 (en) * 2011-06-28 2013-11-26 Konica Minolta Laboratory U.S.A., Inc. System and method for third party authentication of web-based print-on-demand requests
US20130073458A1 (en) * 2011-09-19 2013-03-21 Cardinalcommerce Corporation Open wallet for electronic transactions
WO2013044152A1 (en) * 2011-09-21 2013-03-28 Visa International Service Association Merchant structure hierarchies for mediating transaction data access
GB201117293D0 (en) * 2011-10-07 2011-11-16 Mgt Plc Secure payment system
US8713656B2 (en) 2011-10-23 2014-04-29 Gopal Nandakumar Authentication method
US20130104197A1 (en) 2011-10-23 2013-04-25 Gopal Nandakumar Authentication system
EP2798580A4 (en) * 2011-12-29 2015-09-23 Intel Corp METHOD AND SYSTEM FOR MANAGING MULTIPLE ELECTRONIC PURCHASE DATA CARDS FROM USERS
US10304093B2 (en) 2013-01-24 2019-05-28 Groupon, Inc. Method, apparatus, and computer readable medium for providing a self-service interface
US10255620B1 (en) 2013-06-27 2019-04-09 Groupon, Inc. Fine print builder
US10664876B1 (en) 2013-06-20 2020-05-26 Groupon, Inc. Method and apparatus for promotion template generation
US10304091B1 (en) 2012-04-30 2019-05-28 Groupon, Inc. Deal generation using point-of-sale systems and related methods
US10147130B2 (en) 2012-09-27 2018-12-04 Groupon, Inc. Online ordering for in-shop service
US10664861B1 (en) 2012-03-30 2020-05-26 Groupon, Inc. Generating promotion offers and providing analytics data
US9996859B1 (en) 2012-03-30 2018-06-12 Groupon, Inc. Method, apparatus, and computer readable medium for providing a self-service interface
US10192243B1 (en) 2013-06-10 2019-01-29 Groupon, Inc. Method and apparatus for determining promotion pricing parameters
US20150066765A1 (en) * 2012-03-30 2015-03-05 Ip Payovation Pty Ltd Payment apparatus and method
US11386461B2 (en) 2012-04-30 2022-07-12 Groupon, Inc. Deal generation using point-of-sale systems and related methods
US20130325722A1 (en) * 2012-05-29 2013-12-05 Inder Mohan Payment reconciliation system
US9576279B2 (en) * 2012-06-05 2017-02-21 Autoscribe Corporation System and method for registering financial accounts
US10229412B1 (en) 2012-09-13 2019-03-12 Square, Inc. Using card present transaction data to generate payment transaction account
US10235692B2 (en) 2012-10-17 2019-03-19 Groupon, Inc. Consumer presence based deal offers
US20140108247A1 (en) 2012-10-17 2014-04-17 Groupon, Inc. Peer-To-Peer Payment Processing
CN103780592B (zh) * 2012-10-24 2017-04-26 阿里巴巴集团控股有限公司 一种用户账号被盗确定方法及装置
CN102930431B (zh) * 2012-10-29 2016-01-27 东莞宇龙通信科技有限公司 支付服务器和支付通道标识方法
US11120414B1 (en) 2012-12-04 2021-09-14 Square, Inc. Systems and methods for facilitating transactions between payers and merchants
US9947007B2 (en) 2013-01-27 2018-04-17 Barry Greenbaum Payment information technologies
US20140229375A1 (en) 2013-02-11 2014-08-14 Groupon, Inc. Consumer device payment token management
US9852409B2 (en) 2013-03-11 2017-12-26 Groupon, Inc. Consumer device based point-of-sale
US9576286B1 (en) 2013-03-11 2017-02-21 Groupon, Inc. Consumer device based point-of-sale
US10482511B1 (en) 2013-03-12 2019-11-19 Groupon, Inc. Employee profile for customer assignment, analytics and payments
WO2014166523A1 (en) * 2013-04-09 2014-10-16 Nokia Solutions And Networks Oy Method and apparatus for generating insight into the customer experience of web based applications
GB2513125A (en) 2013-04-15 2014-10-22 Visa Europe Ltd Method and system for transmitting credentials
RU2674329C2 (ru) 2013-07-15 2018-12-06 Виза Интернэшнл Сервис Ассосиэйшн Обработка защищенных удаленных платежных транзакций
WO2015013548A1 (en) * 2013-07-24 2015-01-29 Visa International Service Association Systems and methods for interoperable network token processing
KR102552606B1 (ko) 2013-08-15 2023-07-06 비자 인터네셔널 서비스 어소시에이션 보안 요소를 이용한 보안 원격 지불 거래 처리
US9805366B1 (en) 2013-09-16 2017-10-31 Square, Inc. Associating payment information from a payment transaction with a user account
CN105745678B (zh) * 2013-09-20 2022-09-20 维萨国际服务协会 包括消费者认证的安全远程支付交易处理
US9928493B2 (en) 2013-09-27 2018-03-27 Groupon, Inc. Systems and methods for providing consumer facing point-of-sale interfaces
EP3120593B1 (en) 2014-03-19 2018-12-12 Bluefin Payment Systems, LLC Systems and methods for creating fingerprints of encryption devices
US9461973B2 (en) 2014-03-19 2016-10-04 Bluefin Payment Systems, LLC Systems and methods for decryption as a service
US11256798B2 (en) 2014-03-19 2022-02-22 Bluefin Payment Systems Llc Systems and methods for decryption as a service
US20160005023A1 (en) * 2014-07-07 2016-01-07 Google Inc. Conducting financial transactions by telephone
CN105335850A (zh) * 2014-07-31 2016-02-17 阿里巴巴集团控股有限公司 一种网络支付控制方法和装置
US11210669B2 (en) * 2014-10-24 2021-12-28 Visa International Service Association Systems and methods to set up an operation at a computer system connected with a plurality of computer systems via a computer network using a round trip communication of an identifier of the operation
CN104318439A (zh) * 2014-10-29 2015-01-28 重庆智韬信息技术中心 动态授权码安全支付的短消息授权方法
US9600651B1 (en) 2015-01-05 2017-03-21 Kimbia, Inc. System and method for determining use of non-human users in a distributed computer network environment
CN107408244B (zh) * 2015-03-06 2021-12-31 万事达卡国际股份有限公司 安全移动远程支付
US20160371685A1 (en) * 2015-06-16 2016-12-22 Ned M. Smith System, apparatus and method for providing randomly generated codes in a user anonymous manner
US10339529B2 (en) * 2015-11-18 2019-07-02 Mastercard Internatioinal Incorporated Rules engine for applying rules from a reviewing network to signals from an originating network
US10430795B2 (en) 2015-11-18 2019-10-01 Mastercard International Incorporated Rules engine for applying rules from a reviewing network to signals from an originating network
US10489777B2 (en) * 2016-01-05 2019-11-26 Visa International Service Association Universal access to an electronic wallet
CN106952088A (zh) * 2016-01-06 2017-07-14 向祖跃 无中心多行共享移动支付系统及其支付方法
CA3009672C (en) * 2016-01-27 2022-06-07 Visa International Service Association Accepting issuer credentials at checkout
CN107122975A (zh) * 2016-02-25 2017-09-01 优识空间股份有限公司 用于建议优选支付卡的方法与装置
US10949822B2 (en) * 2016-03-25 2021-03-16 Stripe Inc. Methods and systems for providing payment interface services using a payment platform
US20170278124A1 (en) * 2016-03-28 2017-09-28 Visa International Service Association Merchant loyalty account enrollment through payment checkout platform services
US20170286994A1 (en) * 2016-03-29 2017-10-05 SETA International LLC Power buy system
CN106127568A (zh) * 2016-06-15 2016-11-16 中国人民银行清算总中心 跨行支付系统的清算业务队列解救方法及装置
EP3261034A1 (en) 2016-06-23 2017-12-27 Mastercard International Incorporated Method and system for authorizing and processing payment transactions over a network
CN106204258A (zh) * 2016-07-22 2016-12-07 福建节点信息科技有限公司 一种企业资金风险移动管控系统及管控方法
EP3285220A1 (en) * 2016-08-18 2018-02-21 Mastercard International Incorporated Transaction control management
US20180114203A1 (en) * 2016-10-21 2018-04-26 Mastercard International Incorporated Systems and methods for regulating access to data stored in a data source
US10484415B1 (en) * 2016-12-16 2019-11-19 Worldpay, Llc Systems and methods for detecting security risks in network pages
JP7222484B2 (ja) * 2017-06-02 2023-02-15 ブルーフィン ペイメント システムズ エルエルシー セキュアなインラインフレームを使用したオンライン支払い処理のシステムおよび方法
EP3631718A4 (en) 2017-06-02 2020-12-16 Bluefin Payment Systems, LLC SYSTEMS AND METHODS FOR MANAGING A PAYMENT TERMINAL USING A WEB BROWSER
US11711350B2 (en) 2017-06-02 2023-07-25 Bluefin Payment Systems Llc Systems and processes for vaultless tokenization and encryption
CN107516206A (zh) * 2017-08-10 2017-12-26 清远网软网络科技有限公司 一种旅游网络商城的支付系统
SE1830356A1 (en) * 2018-12-07 2020-06-08 Omnicorn Ab Purchase Management System And Method
DE112020002160T5 (de) * 2019-04-29 2022-01-13 Apple Inc. System und verfahren zum betreiben einer sicheren kontaktlosen transaktion
EP4018618A4 (en) 2019-05-13 2023-10-25 Bluefin Payment Systems, LLC VAULTLESS TOKENIZATION AND ENCRYPTION SYSTEMS AND METHODS
CN110264171B (zh) * 2019-06-06 2023-04-18 深圳前海微众银行股份有限公司 分布式账单处理方法、装置、设备与计算机可读存储介质
US11488149B2 (en) 2019-08-08 2022-11-01 Capital One Services, Llc Management of credentials and authorizations for transactions
US11636194B2 (en) 2020-08-27 2023-04-25 The Toronto-Dominion Bank Method and system for obtaining consent to perform an operation
US20220230145A1 (en) * 2021-01-15 2022-07-21 Fastr Tech Inc. Electronic receipt transmittal apparatus and method

Family Cites Families (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2059078C (en) 1991-02-27 1995-10-03 Alexander G. Fraser Mediation of transactions by a communications system
US5708422A (en) 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
JP2000512405A (ja) 1996-04-26 2000-09-19 ヴェリフォウン、インク 認可装置を使って電子ネットワーク認可をするシステム、方法及びそれを行う機器
US5983208A (en) * 1996-06-17 1999-11-09 Verifone, Inc. System, method and article of manufacture for handling transaction results in a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US6601761B1 (en) 1998-09-15 2003-08-05 Citibank, N.A. Method and system for co-branding an electronic payment platform such as an electronic wallet
US6092053A (en) * 1998-10-07 2000-07-18 Cybercash, Inc. System and method for merchant invoked electronic commerce
KR20020006625A (ko) * 1998-11-17 2002-01-23 추후제출 중간계정을 이용하는 전자 지불 시스템
EP1006469A1 (en) 1998-12-02 2000-06-07 Koninklijke KPN N.V. System for secure transactions
WO2000067216A1 (en) 1999-05-03 2000-11-09 The Chase Manhattan Bank A banking card associated with a cash account
US6609113B1 (en) 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US7742943B2 (en) * 1999-06-23 2010-06-22 Signature Systems Llc Method and system for issuing, aggregating and redeeming merchant loyalty points with an acquiring bank
EP1077436A3 (en) 1999-08-19 2005-06-22 Citicorp Development Center, Inc. System and method for performing an on-line transaction using a single-use payment instrument
KR100373507B1 (ko) * 1999-10-04 2003-02-25 이동산 전자 상거래 시스템 및 전자 상거래 방법
AU784041B2 (en) 1999-11-30 2006-01-19 Citibank, N.A. System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
US7966259B1 (en) 1999-12-09 2011-06-21 Amazon.Com, Inc. System and methods for facilitating transactions on, and personalizing web pages of, third party web sites
US6980970B2 (en) * 1999-12-16 2005-12-27 Debit.Net, Inc. Secure networked transaction system
JP2001216461A (ja) * 2000-02-04 2001-08-10 Just Syst Corp オンライン商品購入システム及び方法、オンライン商品購入指示装置及び方法、オンライン商品購入代理装置及び方法、並びに記録媒体
AUPQ556600A0 (en) * 2000-02-14 2000-03-02 Ong, Yong Kin (Michael) Electronic funds transfers-zipfund
EP1510984A3 (en) 2000-03-01 2005-06-08 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
WO2001082246A2 (en) 2000-04-24 2001-11-01 Visa International Service Association Online payer authentication service
US7516100B1 (en) * 2000-05-12 2009-04-07 The Western Union Company Method and system for transferring money in business-to-business internet transactions
WO2002001447A1 (en) 2000-06-29 2002-01-03 Jonathan Ferrier An e-commerce system
US7890433B2 (en) * 2000-06-30 2011-02-15 Tara Chand Singhal Private and secure payment system
CA2411979A1 (en) * 2000-07-11 2002-01-17 Paypal, Inc. System and method for third-party payment processing
CA2349306C (en) 2000-07-19 2006-10-10 Avaya Technology Corp. Method of and apparatus for executing automated transactions
WO2002025495A1 (en) 2000-09-21 2002-03-28 Trintech Limited A computerized method and system for a secure on-line transaction using cardholder authentication
AUPR193600A0 (en) 2000-12-06 2001-01-04 Globaltech Pty Ltd System and method for third party facilitation of electronic payments over a network of computers
US20020178115A1 (en) * 2001-05-28 2002-11-28 Dong-Seok Seo System and method for supplying credit card information
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
WO2003088078A2 (en) 2002-04-08 2003-10-23 Exxonmobil Research And Engineering Company System and method for processing financial transactions using multi-payment preferences
US7707120B2 (en) 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
EP1379045B1 (en) 2002-07-01 2007-10-10 Telefonaktiebolaget LM Ericsson (publ) Arrangement and method for protecting end user data
US8930270B2 (en) 2002-07-30 2015-01-06 Aol Inc. Smart payment instrument selection
US7478057B2 (en) * 2002-11-29 2009-01-13 Research In Motion Limited Method for conducting an electronic commercial transaction
GB2397731B (en) 2003-01-22 2006-02-22 Ebizz Consulting Ltd Authentication system
US7457778B2 (en) * 2003-03-21 2008-11-25 Ebay, Inc. Method and architecture for facilitating payment to e-commerce merchants via a payment service
GB0308629D0 (en) 2003-04-14 2003-05-21 Tagboard Ltd Payment apparatus and method
AU2003903229A0 (en) 2003-06-25 2003-07-10 Ewise Systems Pty Ltd A system and method for facilitating on-line payment
US20050015304A1 (en) * 2003-07-17 2005-01-20 Yigal Evroni Secure purchasing over the internet
US7039611B2 (en) 2003-11-06 2006-05-02 Visa U.S.A., Inc. Managing attempts to initiate authentication of electronic commerce card transactions
US7580857B2 (en) * 2004-04-16 2009-08-25 First Data Corporation Methods and systems for online transaction processing
US7210620B2 (en) * 2005-01-04 2007-05-01 Ameriprise Financial, Inc. System for facilitating online electronic transactions
EP1856674A4 (en) 2005-02-01 2009-11-11 Source Inc SECURE TRANSACTION SYSTEM
US8041646B2 (en) * 2005-06-15 2011-10-18 E. E. System Corporation Method and system for real time online debit transactions
WO2007125316A2 (en) * 2006-04-25 2007-11-08 Uc Group Ltd. Systems and methods for conducting financial transactions over a network
US20070250441A1 (en) * 2006-04-25 2007-10-25 Uc Group Limited Systems and methods for determining regulations governing financial transactions conducted over a network
EP1873704A1 (en) * 2006-06-30 2008-01-02 MediaKey Ltd. Method and system for determining whether the origin of a payment request is a specific e-commerce network source
US7673332B2 (en) * 2006-07-31 2010-03-02 Ebay Inc. Method and system for access authentication
EP1887506A1 (en) 2006-08-10 2008-02-13 Jepay SAS Electronic commerce transaction process
GB0621189D0 (en) * 2006-10-25 2006-12-06 Payfont Ltd Secure authentication and payment system
US20080103923A1 (en) * 2006-10-31 2008-05-01 Digital River, Inc. Centralized Payment Gateway System and Method
GB2457204A (en) * 2006-11-16 2009-08-12 Net1 Ueps Technologies Inc Secure financial transactions
WO2008127431A2 (en) 2006-11-21 2008-10-23 Verient, Inc. Systems and methods for identification and authentication of a user
CA2675615A1 (en) 2007-01-16 2008-07-24 Autoscribe Corporation System and method for electronic payment processing
WO2008098163A2 (en) 2007-02-09 2008-08-14 Hopton Robert M Method to facilitate confidential network sales
US8793184B2 (en) * 2007-02-12 2014-07-29 Visa U.S.A. Inc. Mobile payment services
MX2009008826A (es) 2007-02-27 2009-12-14 Emigrant Bank Metodo y sistema para facilitar una compra entre un comprador y un vendedor.
WO2008119168A1 (en) 2007-04-03 2008-10-09 Cpni Inc. A system and method for merchant discovery and transfer of payment data
CN101711383B (zh) 2007-04-17 2016-06-08 维萨美国股份有限公司 用于认证交易方的方法和系统
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
US8121956B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Cardless challenge systems and methods
US8204825B2 (en) 2007-07-16 2012-06-19 American Express Travel Related Services Company, Inc. System, method and computer program product for processing payments
US8660893B2 (en) 2007-07-23 2014-02-25 Visa U.S.A. Inc. Multi-vendor multi-loyalty currency program
US20100106611A1 (en) * 2008-10-24 2010-04-29 Uc Group Ltd. Financial transactions systems and methods

Also Published As

Publication number Publication date
US20100174626A1 (en) 2010-07-08
AU2010204316A1 (en) 2011-07-28
AU2010204316B2 (en) 2016-06-30
CA2748913A1 (en) 2010-07-15
EP2386096A1 (en) 2011-11-16
CA2748913C (en) 2017-03-14
GB0900150D0 (en) 2009-02-11
US20120030066A1 (en) 2012-02-02
KR20110134381A (ko) 2011-12-14
GB2466676A (en) 2010-07-07
CN102341817B (zh) 2015-09-02
WO2010079182A1 (en) 2010-07-15
US8706577B2 (en) 2014-04-22
HK1166871A1 (zh) 2012-11-09
KR101658684B1 (ko) 2016-09-30
CN102341817A (zh) 2012-02-01
US8942997B2 (en) 2015-01-27

Similar Documents

Publication Publication Date Title
US11669816B2 (en) Payment system
AU2010204316B2 (en) Payment system
JP6472782B2 (ja) 仲介人介在支払システムおよび方法
JP5455269B2 (ja) サードパーティ支払い処理のシステムおよび方法
JP6513254B2 (ja) 仲介業者によって媒介される支払いシステムおよび方法
US8301500B2 (en) Ghosting payment account data in a mobile telephone payment transaction system
AU2011100451B4 (en) Online transaction system
KR20090060225A (ko) 입금경로 별 상점 회계정보를 통한 대출금액 산출 방법