MX2011007356A - Sistema de pago. - Google Patents

Sistema de pago.

Info

Publication number
MX2011007356A
MX2011007356A MX2011007356A MX2011007356A MX2011007356A MX 2011007356 A MX2011007356 A MX 2011007356A MX 2011007356 A MX2011007356 A MX 2011007356A MX 2011007356 A MX2011007356 A MX 2011007356A MX 2011007356 A MX2011007356 A MX 2011007356A
Authority
MX
Mexico
Prior art keywords
payment
account
commercial
online
transaction
Prior art date
Application number
MX2011007356A
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 MX2011007356A publication Critical patent/MX2011007356A/es

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/227Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

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; las solicitudes de autorización de pago se conducen como un resultado de pedidos por titulares de cuentas financieras vía una pluralidad de diferentes sistemas comerciales en línea, y el titular de cuentas financieras mantiene cuentas con una pluralidad de diferentes bancos emisores. El método comprende conducir un procedimiento de identificación de cuenta que comprende: identificar, de la pluralidad de diferentes bancos emisores, un banco emisor asociado con un titular de cuentas financieras; sobre la base de la identificación del banco emisor, recuperar los datos de transmisión de banco emisor para habilitar la transmisión de datos de solicitud de identificación de cuenta, los datos de transmisión de banco emisor son dependientes del banco emisor identificado e identificar un sistema de identificación de cuenta seleccionada asociado con el banco emisor identificado; sobre la base de los datos de transmisión de banco emisor recuperados, transmitir una solicitud de identificación de cuenta para uso en la autorización de al menos una transacción de pago, al menos una transacción de pago se inicia como un resultado de que un titular de cuentas financieras conduce al menos un pedido vía al menos un sistema comercial en línea; y recibir una respuesta de identificación de cuenta en respuesta a la solicitud de identificación de cuenta, la respuesta de identificación de cuenta identifica una identidad de cuenta financiera capaz de ser usada en al menos una transacción de pago. Por consiguiente, las modalidades de la invención proporcionan un medio para identificar un bando emisor de una pluralidad de bancos emisores como uno el cual será utilizado en una transacción dada y facilitar que un usuario especifique, en tiempo real con relación a la transacción dada, una cuenta de banco particular que será usada para deducir fondos por esta transacción.

Description

SISTEMA. DE PAGO CAMPO DE LA INVENCIÓN La presente invención se refiere a un sistema y método de pago de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos y es particularmente, pero no exclusivamente, adecuado para solicitudes de autorización de pago que se conducen como un resultado de los pedidos por titulares de cuentas financieras vía una pluralidad de diferentes sistemas comerciales en linea. i i ANTECEDENTES DE LA INVENCIÓN i 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 cuatro tipos de arreglo: 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 2 sistema de banco adquisidor. En un segundo tipo de arreglo, el sistema comercial en línea colecta los detalles del pago de un comprador sin que el comprador trate directamente con alguna otra identidad que puede estar involucrada 1 en la transacción, y el sistema comercial en línea en ía los detalles de la transacción a un Proveedor de Servicios de Pagos por Internet comercial en línea (sistemá IPSP comercial) el cual procesa las autorizaciones de pago en beneficio del comercio. El sistema IPSP coinercial 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 comerciales los cuales proporcionan soporte para este segundo tipo de arreglo incluyen el sistema de Pagos Protx™ Veri-Secure (VSP) . Una ventaja de usar una puerta de acceso de pagos tal cómo el sistema IPSP comercial mencionado antes es que el sistema IPSP comercial puede proporcionar una o más diversas 1 funciones de procesamiento de transacción adicionales, por ejemplo liquidación, manejo de devoluciones de cargos, manejo i de reembolsos, e informe de transacciones, en beneficio del comercio en línea. En el procedimiento de liquidación, el sistema IPSP comercial presenta todas las autorizaciones aprobadas del comercio en línea colectadas durante un período 1 1 I I dado, en un "lote", al sistema de banco adquisidor del comercio en línea 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 línea, vía el 'sistema I IPSP comercial. 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, 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 intervalo de fechas seleccionado. Un sistema IPSP comercial puede proveer a un i comercio en línea con un sitio web en línea seguro para aprobar las devoluciones de cargo, iniciar los reembolsos y/o ver los informes de transacción como se describe. ! En un tercer tipo de arreglo el sistema comercial en línea 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 I pago al sistema de pago alternativo ya sea directamente de su cuenta de banco o vía un mecanismo tal como una tarj!eta de pago. Donde se usa una tarjeta de pago de un esquema de pago 4 : 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 sistema de pago i 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 i sistema de pago alternativo de la cuenta de banco emisor actual del usuario cargando una suma directamente a su I 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 mantenida 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 i 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én1 puede í tener la capacidad de operar como un IPSP convencional, por ejemplo, proporcionando servicios de manejo de pagos en linea asociados. 1 Mientras que este tipo de sistema de pago alivia la 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 y1 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. ¡ Cuando el usuario interactúa solamente con el sistema comercial, el sistema comercial típicamente obtiene datos de la tarjeta de pago, información de la cuenta de 6 I banco y/u otros datos financieros del comprador. El comercio entonces pasa esta información ya sea directamente o vía una puerta de acceso de pagos proporcionada por un sistema IPSP comercial, a un sistema de procesamiento de banco adquisidor. Cada sistema comercial es asignado con un identificador de cuenta de comercio por un banco adquisidor, y este identificador de cuenta se usa para identificar el comercio i al banco adquisidor cuando solicita autorización de una transacción. Esto requiere que cada sistema comercial implemente su propia capacidad de procesamiento de pago, aislado de otros comercios; como un resultado que se requiere que un comprador proporcione su información de pago separadamente para cada comercio. Por consiguiente, paira cada nuevo comercio con el que un comprador interactlia, se incrementa el riesgo de exposición, malversación y/o uso I fraudulento de los datos financieros del comprador.
Estos sistemas de pago conocidos requieren que el usuario ingrese sus detalles de la cuenta en una base por transacción o en registro con el IPSP comercial, o alternativo, sistema de pago no IPSP; por consiguiente el usuario es el único punto de contacto para procurar los detalles de pago relevantes. Mientras que es un procedimiento aceptado, los identificadores de cuenta tienen !a ser .1 difíciles de recordar, y como un resultado los usuarios generalmente pueden hacer solamente compras y/o firmar para í pagar servicios y sitios comerciales cuando tienen sus detalles de cuenta con ellos en el punto de tiempo relevante.
En un cuarto tipo de arreglo de un sistema de pago, se proporciona una opción adicional por lo cual un comprador es capaz de seleccionar proceder a pagar vía su banco 'emisor, el cual proporciona un sitio web de banca en linea para tales propósitos. Sin embargo, en este caso el comercio en linea, o el sistema IPSP comercial que actúa en su beneficio, necesita interconectarse con el sistema del banco emisor y además, el proceso de pago, una vez transferido al banco emisor, procede como una transferencia de tipo de pago de facturas directamente de la cuenta de transacciones del usuario (es I decir, una cuenta corriente o cuenta de cheques) mantenida por el sistema de banco emisor. Por lo tanto, las funciones de procesamiento disponibles de los sistemas IPSP comerciales existentes o de sistemas de esquema de tarjeta existentes I (tales como Visa™ y Mastercard™) .
Breve Descripción de la Invención De conformidad con al menos una modalidad de la i invención, los sistemas y software se proporcionan p ra un método de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red i de comunicaciones de datos, como se especifica en las reivindicaciones independientes. Esto se logra por una i ! I 8 combinación de características citadas en cada reivindicación independiente. Por onsiguiente, 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 de procesamiento de solicitudes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos, las solicitudes de autorización de pago se conducen como un resultado de pedidos por titulares de cuentas financieras vía una pluralidad de diferentes sistemas comerciales en línea, en donde los titulares de cuentas financieras mantienen cuentas con una pluralidad de diferentes bancos emisores, el método comprende conducir un procedimiento de identificación de cuenta que comprende: j identificar, de la pluralidad de diferentes bancos emisores, un banco emisor asociado con un titular de jcuentas financieras; sobre la base de la identificación del! banco emisor, recuperar los datos de transmisión de banco emisor para habilitar la transmisión de datos de solicitud de identificación de cuenta, los datos de transmisión de banco i emisor son dependientes del banco emisor identificado e identificar un sistema de identificación de cuenta 9 seleccionada asociado con el banco emisor identificado; sobre la base de los datos de transmisión de banco emisor recuperados, transmitir una solicitud de identificación de cuenta para uso en la autorización de al menos una transacción de pago, al menos unas transacciones de pago se inician como un resultado de que un titular de cuentas financieras conduce al menos un pedido vía al menos i un sistema comercial en línea; y recibir una respuesta de identificación de I cuenta i en respuesta a la solicitud de identificación de cuenta, la i respuesta de identificación de cuenta identifica una identidad de cuenta financiera capaz de ser usada en al menos una transacción de pago. i Por consiguiente, las modalidades de la invención proporcionan un medio para identificar un banco emisor 'de una pluralidad de bancos emisores como uno el cual será utilizado en una transacción dada. Las modalidades de la invención proporcionan un medio para que un usuario especifique, en tiempo real con relación a la transacción dada, una cuenta de banco particular que será usada para deducir fondos paira esta transacción. Preferiblemente, el usuario es autenticaido con relación a su cuenta, y por consiguiente proporciona un i mejoramiento sobre los sistemas conocidos en los cuales un I usuario ya sea tiene que enviar detalles del pago¡ a un sistema comercial o proporcionar detalles por adelantado de í I i 10 la transacción, por ejemplo a una entidad de tercera 'parte a quién el usuario ha autorizado previamente para manejar el pago en su beneficio. Se entenderá que por banco emisor se entiende un banco que mantiene una cuenta en beneficio de un usuario, esta cuenta puede o no puede ser acompañada por una i tarjeta de pago, y en efecto las modalidades de la invención se aplican igualmente a usuarios que tienen cuentas con sus bancos emisores para los cuales las tarjetas no son emitidas. En términos generales, el banco emisor se podrá considerar una entidad de pago (el pagador) en la transacción de pago.
En un arreglo el método adicionalmente comprende, después de recibir la respuesta de identificación de cuenta: a) generar una solicitud de autorización de pago que comprende datos de transacción que incluyen: I i) una identidad de cuenta financiera que se usa en una transacción ,de pago por el titular de la cuenta financiera; y i ii) una identidad de comercio, asociada con un primer comercio en línea, como el I beneficiario de la transacción de pago; y I iii) detalles de la transacción incluyendo una cantidad del pago; y ' i b) transmitir la solicitud de autorización de pago generada para el procesamiento subsecuente por 11 un sistema procesador de pago de banco adquisidor responsable del procesamiento de autorizaciones de pago para un banco adquisidor con el cual el primer comercio en linea se asocia. 1 Esto habilita a la identidad de cuenta financiera que sea acoplada con una transacción solicitada como parte de un proceso extremo a extremo, y tiene el beneficio de reducir el riesgo de detalles de transacción que se separan de los detalles del pago. Por consiguiente, la solicitud de autorización de pago preferiblemente se genera en respuesta a la recepción de la respuesta de identificación de cuenta.
Las modalidades de la invención habilitan la generación de una pluralidad de solicitudes de autorización de pago incluyendo la misma identidad de cuenta financiera: se puede conducir un procedimiento de identificación de cuenta separado para cada solicitud de autorización dé pago, que involucra transmitir una solicitud de identificación de cuenta y recibir la respuesta de identificación de cuenta, antes de la generación de cada una de las solicitudes de autorización de pago. En este caso el método puede comprender generar una pluralidad de solicitudes de autorización de pago incluyendo la misma identidad de cuenta financiera, y para cada una de la pluralidad de solicitudes de autorización de pago, mantener la identidad de cuenta financiera, de modo que solamente un procedimiento de identificación de cuenta 'único, I I 12 I el cual incluye transmitir una solicitud de identificación de i cuenta y recibir una respuesta de identificación de cuenta, se requiere para todas de la pluralidad de solicitudes de autorización de pago. Este arreglo tiene la ventaja de limitar el uso de anchura de banda requerido para comunicarse i con el banco emisor identificado. ! En una modalidad preferida, la red de comunicaciones de datos comprende una pluralidad de diferentes sistemas Proveedores de Servicio de Pago por Internet comerciales (sistema IPSP comercial) . 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 i adquisidor; cada uno de la pluralidad de sistemas procesadores de pago de banco adquisidor es responsable de procesar autorizaciones de pago para al menos un1 banco adquisidor; y cada uno de una pluralidad de comercios en linea se asocia con uno de la pluralidad de sistemas IPSP comerciales. En este arreglo el método comprende recuperar datos de transmisión de sistema IPSP comercial 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 de sistema IPSP comercial recuperados, transmitir I la solicitud de autorización de pago generada al sistema IPSP I i I 13 comercial seleccionado. Una solicitud de autorización de pago adicional luego se puede generar y transmitir a un ¡ sistema procesador de pago de banco adquisidor responsáble de procesar autorizaciones de pago para el banco adquisidor con el cual el primer comercio en linea está asociado. Un sistema I IPSP comercial proporciona un sistema que pasa los datos de la tarjeta, solicitudes de autorización, y respuestas de autorización sobre la Internet usando tecnología de encriptación, y por consiguiente mejora la seguridad' de una i solicitud de autorización de pago dada.
I El método preferiblemente comprende recibir una identidad de comercio del primer sistema comercial en línea, la identidad de comercio incluida en la solicitud de autorización generada se genera sobre la base de la identidad de comercio recibida. Por consiguiente, el identific dor de cuenta de comercio es el que se transmite al banco adquisidor. Como un resultado, la relación para tales transacciones está 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 por cualquier protección al consumidor aplicable. ' I En una modalidad particularmente preferida, el método se conduce por un sistema intermediario confiable, el método comprende el sistema intermediario confiable que recibe de los sistemas comerciales en línea responsables para 14 originar solicitudes de autorización de pago para comercios en linea, solicitudes de autorización de pago relacionadas con la autorización de transacciones de pago, las solicitudes de autorización de pago recibidas se inician como un resultado de que los titulares de cuentas financieras conducen un pedido vía los sistemas comerciales en linea. Tener la entidad centralizada coordinando las diversas comunicaciones tiene los beneficios de escalabilidad: en particular el procedimiento de identificación de cuenta se puede conducir por el sistema intermediario confiable en i respuesta a la recepción de una solicitud de autorización de i pago de un sistema comercial en linea; el sistema intermediario confiable puede recibir una respuesta de i autorización de pago, y en respuesta a esto transmitir una I respuesta de autorización de pago al primer sistema comercial I en línea. i Además, el sistema intermediario confiable puede proporcionar una interfaz de registro para comercios en línea por lo cual los comercios en línea pueden registrar un I sistema IPSP comercial con el cual se asocian, y la etapa de recuperación de 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 puede conducir sobre la base del sistema IPSP comercial registrado por el primer comercio en línéa. i 15 I Cuando las transacciones, las cuales son autorizadas usando el sistema de la presente invención, se procesan por el sistema IPSP comercial, las funciones del I i 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 incluyen tanto tipos de transacción para los i cuales las solicitudes de autorización de pago se originan vía el sistema intermediario confiable como otros tipos de transacción separadamente autorizadas los cuales se i pueden procesar por el IPSP en beneficio del comercio sin pasar vía i el sistema intermediario confiable. Esta interfaz común puede comprender un sitio web en linea seguro.
Para usuarios que tienen una pluralidad de diferentes cuentas financieras, el método comprende recibir datos que indican una selección, por el titular de cuentas financieras, entre una pluralidad de tales diferentes cuentas financieras para uso en la transacción de pago, y recuperar una identidad de cuenta financiera sobre la base de la i selección indicada. Convenientemente esto se facilita vía una i interfaz de selección de cuenta para un titular de cuentas financieras por lo cual el titular de cuentas financieras puede seleccionar una identidad de cuentas financieras.! I La etapa de recuperar datos de transmisión de banco emisor puede comprender recuperar una dirección de red para 16 I el sistema de identificación de cuenta seleccionada; en algunos arreglos la dirección de red se puede transmitir a un titular de cuentas financieras para habilitar al titular de cuentas financieras para acceder al sistema de identificación de cuenta seleccionada. Específicamente, el titular de cuentas financieras es capaz de conducir un procedimiento de identificación proporcionando información de identificación al sistema de identificación de cuenta seleccionada. Además, en tales arreglos la respuesta de identificación de cuenta se recibe por el titular de cuentas financieras del sistema intermediario confiable seleccionado en respuesta a la autenticación del titular de cuentas financieras por el sistema de identificación de cuenta seleccionada. 1 En algunas modalidades la identidad de : cuenta financiera comprende un Número de Cuenta Principal (PAN) asociado con el titular de cuentas financieras - por ejemplo en la forma de un número de tarjeta de pago. Alternativamente la identidad de cuenta financiera puede comprender un, Número de Cuenta de Banco Internacional (IBAN), o alternativamente un identificador de banco, el cual preferiblemente , es un identificador de banco internacional tal como código de país i y código de clasificación, o código BIC, y un numero de I cuenta. Sin embargo, un formato PAN es preferido puesto que i está en el formato el cual se procesa usando pagos de esquema de tarjeta existentes. i I 17 i De acuerdo con un aspecto adicional de la presente invención se proporciona un método para autorizar transacciones de pago conducidas vía una red de comunicaciones de datos, una transacción de pago se ¡conduce como un resultado de un pedido por un titular de cuenta financiera vía un sistema de procesamiento de datos I comercial, el método comprende acceder a los detalles de autenticación de banca en linea almacenados por un proceso de autenticación de banca en linea por lo cual un titular de cuentas financieras es capaz de acceder a una aplicación de I banca en linea, la aplicación de banca en linea se relaciona con al menos unas cuentas financieras del titular de puentas financieras, en donde el método comprende: | recibir una solicitud relacionada con la I autorización de una transacción de pago, la solicitud se inicia como un resultado de que un titular de cuentas financieras conduce un pedido en un sistema de procesamiento de datos comercial; 1 i en respuesta a la recepción de la solicitud, i conducir un proceso de autenticación de pago en el cual el titular de cuentas financieras proporciona detalles de autenticación correspondientes a los detalles de autenticación de banca en linea almacenados; en respuesta a la verificación de los detalles de I autenticación introducidos contra los detalles de i I 18 autenticación de banca en linea almacenados, recuperar un número de cuenta principal (PAN) para uso en el procesamiento de pago: ¡ transmitir el número de cuenta principal (PAN) recuperado a un sistema Proveedor de Servicio de Pagos por Internet (sistema IPSP comercial) para uso en la autorización de la transacción de pago. I En algunos arreglos el número de cuenta principal (PAN) se genera solamente para uso único. El proceso de i autenticación de pago se puede conducir por un sistema de procesamiento de datos de banca en linea, mientras que el I método se puede conducir al menos en parte vía un sistema de procesamiento de datos de procesamiento de transacción, se separa del sistema de procesamiento de datos de banca I emisora. Por ejemplo, el método puede comprender que el i sistema de procesamiento de datos de banca emisora transmita el número de cuenta principal (PAN) recuperado al sistema de procesamiento de datos de procesamiento de transacción en I respuesta a la verificación de los detalles de autenticación I ingresados, y el sistema de procesamiento de datos de procesamiento de transacción transmite el número de ! cuenta í principal (PAN) recuperado a un sistema de procesamiento de datos de procesamiento de pago.
En el caso que el número de cuenta principal (PAN) se almacene por el sistema de procesamiento de datos de Í i 19 i procesamiento de transacción, el método comprende recuperar el número de cuenta principal (PAN) , y transmitir el! número de cuenta principal (PAN) a un sistema IPSP comercial en respuesta a la verificación de los detalles de autenticación ingresados. j Se entenderá que los términos "comercio en linea", "sistema IPSP comercial", "sistema intermediario Icentral confiable" y "sistema de procesamiento de datos de i procesamiento de transacción" y "sistema procesador de pago de banco adquisidor" se refieren a componentes lógicos. Como i tal, cada sistema se puede incluir físicamente separado uno de otro o físicamente conectado a uno o más sistemas. Por i 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 i sistema procesador de pago de banco adquisidor, los componentes se podrán ubicar físicamente en la misma red o I 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 I pueden llevar a cabo por una organización que también es el comercio y/o también el adquisidor.
De acuerdo con aspectos adicionales de la invención se proporciona un sistema intermediario confiable en comunicación con unos sistemas comerciales en linea1 y una pluralidad de bancos emisores, cada uno tiene un sistema de identificación de cuenta asociado con este, el sistema intermediario confiable se arregla para ^ conducir el I procedimiento de identificación de cuenta antes mencionado.
I Además, se proporciona un sistema comercial en linea en I comunicación con un sistema intermediario confiable i 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 I 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 comercial1 antes mencionado . i Los aspectos de la invención también proporcionan I software distribuido entre los diversos sistemas, i adecuadamente configurado para realizar el método mencionado antes . i Las características y ventajas adicionales Ide la invención llegarán a ser evidentes a partir de la siguiente í i 21 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 de acuerdo con una primera modalidad de la invención; La Figura 2 es un diagrama esquemático que muestra un sistema de pago de acuerdo con una segunda modalidad de la invención; La Figura 3 es un diagrama esquemático que muestra I un sistema de pago de acuerdo con una modalidad aún adicional de la invención; i La Figura 4 es un diagrama de flujo esquemático que I muestra el flujo de datos durante el uso del sistema de pago de la Figura 3 de acuerdo con una modalidad de la invención; La Figura 5a es un diagrama de bloque esquemático que muestra componentes del sistema intermediario confiable de acuerdo con una modalidad de la invención; ' i La Figura 5b es un diagrama de bloque esquemático i que muestra componentes del sistema intermediario confiable dentro del cual el sistema intermediario confiable de acuerdo con una modalidad de la invención se implementa; La Figura 6 es un diagrama de sincronización í I 22 esquemático que muestra el flujo de mensajes asociados con la selección de cuenta de acuerdo con una modalidad de la invención; Las Figuras 7-10 son diagramas de sincronización esquemáticos que muestran flujos de mensaje alternativos a aquellos mostrados en la Figura 6; y La Figura 11 es un diagrama de flujo esquemático que muestra trayectorias de selección de pago extremo a extremo alternativas, las cuales emplean una modalidad adicional de la invención. ' 23 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 d datos, las solicitudes de autorización de pago se conducen como un resultado de pedidos por titulares de cuentas financieras, i vía un sistema de usuario tal como una computadora personal u otro dispositivo de computación, vía una pluralidad de í diferentes sistemas comerciales en línea.
I La Figura 1 muestra un sistema de pago de acuerdo I con una primera modalidad de la invención, en el cual el i titular de cuentas financieras, que hace uso del sistema de i usuario Ul, mantiene cuentas con una pluralidad de diferentes I bancos emisores 2a, 2b; esto bancos emisores incluyen bancos I que asignan un número de tarjeta de débito apropiado para hacer posible que el pago sea enrutado de nuevo a la cuenta i corriente del consumidor vía el sistema de esquema de tarjeta i a un usuario y asumen la responsabilidad primaria para la capacidad del usuario para liquidar las deudas incurridas con la tarjeta. Sin embargo, y como se describió anteriormente, este caso del banco emisor que asigna una tarjeta al usuario en conjunto con la cuenta de banco del usuario será considerado un ejemplo no limitante de una aplicación¦ de las ! I modalidades de la invención. Como se puede ver de la Figura, el sistema de usuario Ul se conecta vía enlaces de comunicaciones de datos vía los cuales el titular de ;cuentas financieras es capaz de entrar en una transacción coni uno de una pluralidad de sistemas comerciales en linea la, · Ib, 1c cuando se compran mercancías sobre la Internet. Los sistemas comerciales en línea son equipados con software que habilita al usuario a seleccionar un método de pago para la compra de sus mercancías seleccionadas, y en modalidades de la i invención, el software de selección de pago incluye una opción para que el sistema de usuario Ul acceda a un sistema intermediario confiable 4 por lo cual el titular de cuentas financieras es capaz de especificar una cuenta de1 banco particular de la cual el pago será deducido. ' En un arreglo preferido, la selección dé esta opción activa el sistema comercial en línea la para redirigir i al usuario al sistema intermediario confiable 4, luego comienza un procedimiento de identificación de cuenta que involucra el sistema intermediario confiable 4, el usuario Ul y uno de la pluralidad de bancos emisores 2a, 2b. Por consiguiente, la selección de la opción de cuenta de1 banco del software de compras en línea del comercio efectivamente causa que el usuario Ul sea redireccionado y se comunique con i el sistema intermediario confiable 4 y el banco emisor relevante 2b; estas etapas de redirección se indican por I 25 medio de una linea discontinua en la Figura. Se requiere que el titular de cuentas financieras, vía. el sistema, de usuario Ul, especifique, por ejemplo via la selección de una lista desplegable o ingresando datos directamente, un identificador del banco emisor de cual pago será deducido, por ejemplo, en la forma de código de país y nombre del banco (por ejemplo, "GB" y "HSBC") o un código tal como Código Identificador de banco (BIC) , código SWIFT, o un Número de Enrutamiento de banco (también conocido como un Número de Asociación Americana de Banca (ABA) , en donde el sistema intermediario confiable 4 identifica el sistema de banco emisor relevante 2b (por ejemplo, por consulta de una tabla que mantiene detalles del sitio web de banca en linea para un intervalo de bancos emisores) y redirige el sistema de usuario ?? para comunicarse con este. En un arreglo basado n Internet esta redirección puede involucrar dirigir el buscador del ¡usuario a un servidor web asociado con el banco emisor convencionalmente referida como una página de inicio de cesión de banca en linea. El titular de cuentas financieras, via el sistema de usuario Ul, luego ingresa en su cuenta de banco en linea de la manera normal, enviando una solicitud de identificación de cuenta para uso en la autorización de al menos una transacción de pago.
Como se apreciará con más detalle posteriormente I con referencia a la Figura 6, la redirección ocurre bajo el I 26 control del sistema intermediario confiable 4, lo cual es para decir que la página web que se visualiza al usuario se encapsula efectivamente dentro de una página web controlada por, o emitida en asociación con, el sistema intermediario confiable 4. Como un resultado, en la selección de una cuenta de la cual el pago será deducido, el sistema intermediario confiable 4 posteriormente recibe, del banco emisor 2b, una respuesta de identificación de cuenta que identifica una identidad de cuenta financiera capaz de ser usada 1 en la transacción.
Esta respuesta de identificación de cuenta puede comprender un Número de Cuenta Principal (PAN) normalmente asociado con la tarjeta de débito enlazada a la cuenta del usuario; por lo tanto se apreciará que las modalidades de la invención son particularmente bien adecuadas para situaciones en las cuales el usuario Ul desea que ' el pago sea efectuado de un instrumento de pago (típicamente tarjetas y cuentas) . Una vez recibido por el sistema intermediario confiable 4, el PAN entonces se transmite, en la forma de una solicitud de autorización de pago, al procesador del banco adquisidor 5, o beneficiario, asociado con el comercio la, por métodos convencionales en los cuales el usuario ha ingresado detalles de pago en el sistema en línea del comerciante. El PAN es acompañado por la información de transacción e identificador de cuenta del comercio, y el sistema de esquema de tarjeta 7 I enruta la transacción al mismo banco emisor de tarjeta 2b. El banco emisor 2b recibe la solicitud de autorización y envía una respuesta de nuevo al procesador del banco adquisidor del comercio 5 con un código de respuesta, en donde el procesador del banco adquisidor del comercio 5 transmite la respuesta al i sistema intermediario confiable 4. El sistema intermediario confiable 4 entonces transmite la respuesta al sistema del comercio donde se interpreta y una respuesta relevánte se retransmite al titular de la tarjeta y el comercio. La subsecuente liquidación y aclaramiento se manejan en una manera convencional/ e involucra que el banco adquisidor 5 deposite el total de los fondos aprobados en la ' cuenta nominada del comercio. Se apreciará que las comunicaciones asociadas con la parte de liquidación del procesó se ¡ pueden efectuar por implementaciones de mensaje ya sea dual o íúnico.
Mientras que el ejemplo anterior describe la operación del sistema de pago 1 con relación a una solicitud de autorización de pago única que emana del sistema intermediario confiable 4, el sistema 1 también se puede usar para una pluralidad de solicitudes de autorización de1 pago.
I El sistema intermediario confiable 4 podrá conducir un I procedimiento de identificación de cuenta consolidad, que incluye redirigir al usuario Ul al banco emisor identificado para realizar un único procedimiento de solicitud de identificación de cuenta descrito antes para toda la 28 I mensajería de autorización de pago subsecuente !con el procesador de banco adquisidor 5. El usuario Ul 1 podría i realizar el procedimiento de solicitud de identificación de cuenta antes de la generación de cada una de las solicitudes de autorización de pago y enviarlas al procesador de banco i adquisidor 5. Alternativamente, el sistema intermediario I confiable 4 podrá redirigir al usuario para conducir i procedimientos de identificación de cuenta individuales, uno í para cada solicitud de autorización de pago.
La Figura 2 muestra una modalidad alternativa del sistema de pago, en el cual el sistema de pago 1 comprende un (Proveedor de Servicio de Pago por Internet comercial (sistema IPSP comercial), el cual es una puerta de acpeso de pago seleccionada por el comercio para los propósitos de conducir negocios seguros en la Internet. Un sistema IPSP comercial 3 proporciona un sistema que pasa datos i de la tarjeta, solicitudes de autorización, y respuestas de autorización sobre la Internet usando tecnología de encriptación. La información de transacción se envía ¡vía el sistema IPSP comercial 3 al sistema de esquema de tarjeta 7 donde se verifica la validez de la tarjeta y se verifica la disponibilidad de fondos en esta cuenta. Un código de autorización se regresa al sistema adquisidor 5 y al sistema IPSP comercial 3; la autorización se encripta por el sistema i IPSP comercial 3 y se transmite en forma encriptada al 29 sistema intermediario confiable 4, el cual envía una respuesta adecuada al servidor web del comercio la, esto activa el cumplimiento del pedido. Por consiguiente, en esta modalidad el sistema IPSP comercial 3 se involucra en la transmisión de la respuesta de identificación de cuenta al procesador del banco adquisidor 5.
En una modalidad preferida, el sistema intermediario confiable 4 se incluye dentro de una nueva entidad de transacción, referido en la presente como un intermediario confiable, que coopera con otras entidades de pago del sistema de pago 1 como se describirá ahora con referencia a la Figura 3. El intermediario confiable' 10 se muestra siendo capaz de transmitir solicitudes de autorización de pago a cada uno de una pluralidad de diferentes sistemas IPSP comerciales 3a, 3b. Cada uno de los sistemas de procesamiento comerciales en linea la ... ' le se asocia con uno de los sistemas IPSP comerciales 3a, 3b, como se indica por la linea de puntos Ll para uno de los comercios le, asi como también se asocia con uno de los bancos adquisidores 5b, como se indica por la línea de puntos L2, de nuevo para el comercio le. Al menos algunos de los sistemas IPSP comerciales 3a, 3b 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 puede procesar sus pagos vía un sistema IPSP comercial idado, I pero cada uno tiene una cuenta con un banco adquisidor diferente. Además de conformidad con las modalidades de la invención, cada sistema de procesamiento comercial en linea la ... le se ha modificado para incluir, como opción de pago, I 1 "Pago de Cuenta Corriente" (PCA) , esta identifica una solicitud de pago vía el sistema intermediario confiable 4 incluido dentro del intermediario confiable 10.
El intermediario confiable 10 mantiene datos en una base de datos DB1 correspondiente a comercios y bancos emisores que se han registrado con el intermediario confiable i 10, conjuntamente con datos de transacción. Puesto que el intermediario confiable 10 se interconecta con, antes que reemplazar, los sistemas IPSP comerciales existentes del comercio, el identificador de cuenta de comercio es el que se i transmite al banco adquisidor 5b. Por consiguiente, la relación para tales transacciones está entre el comprador y el comercio en linea, con el beneficio resultante que el comprador se protege por las reglas del esquema de tarjeta y por cualquier protección al consumidor aplicable. Además, el sistema IPSP comercial puede proporcionar a un comercio en i linea con una o más diversas funciones de procesamiento de i transacción adicionales, por ejemplo liquidación, manejo devoluciones de cargo, manejo de reembolsos, e informe de transacción, en beneficio del sistema comercial en linea. i Además, debido a que los sistemas de pago de acuerdo con las ¡ I I I I 31 modalidades de la invención involucran la adición del intermediario confiable 10 dentro de un conjunto existente y conocido de entidades de procesamiento, los pagos se pueden hacer de acuerdo con los métodos convencionales usando arreglos de los primer y segundo tipos descritos en la sección de antecedentes en adición, o como una alternativa a, i vía el intermediario confiable 10.
Con referencia ahora a la Figura 4, . ahora se describirá la operación del sistema de pago 1 de acuerdo con una modalidad de la invención. En la etapa S401 el usuario completa su experiencia de compra con el sistema comercial en linea del comercio C's, inicia el pago usando el sistema comercial, 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 "Pago de Cuenta Corriente" (PCA) como una opción de pago (etapa S401), causando que el sistema de procesamiento comercial le transmita un mensaje de solicitud al intermediario confiable 10 (etapa S403) ; el mensaje de solicitud comprende al menos una cantidad del pago para las mercancías seleccionadas, el identificador de cuenta de comercio y un identificador para el pedido. El intermediario confiable 10 luego transmite una URL de inicio de sesión al consumidor (etapa S405) , incitando al usuario a iniciar el I 32 i proceso de selección de cuenta: al usuario se le presenta una página de selección, en la cual el usuario ingresa el nombre y código de país del banco emisor que desean usara para esta transacción, en la manera descrita anteriormente con referencia a la Figura 1 (etapa S407) . El intermediario confiable 10 luego realiza una consulta para obtener la URL del banco emisor relevante y envia una instrucción de I redirección al buscador del usuario, causando que el buscador del usuario sea redirigido a la página de inicio de sesión en linea correspondiente a su banco emisor identificado t (etapa S409) . El usuario Ul ingresa usando sus credenciales de banca en linea (tal como número de cliente, contraseña,, datos personales memorables, etc.), causando que el software de banco emisor envié una lista de detalles de tarjeta de i débito correspondientes y cuentas de pago elegibles para la selección por el usuario Ul (etapa S411) . Como se describió anteriormente, los detalles de la cuenta y tarjeta incluyen el PAN para cada cantidad respectiva.
En la selección de la cantidad deseada el intermediario confiable 10 envia un mensaje de solicitud de autorización al sistema IPSP comercial 3b del comercio, el mensaje de solicitud comprende los detalles de cuenta seleccionada, la cantidad de pago requerida y el í identificador de comercio (etapa S413) . El sistema IPSP i comercial 3b envia una solicitud de autorización al banco i j 33 i adquisidor relevante 5b (etapa S414), incitando1 a la autorización (o de otra manera) por métodos convencionales (etapa S415) y la transmisión de un mensaje de respuesta del banco adquisidor 5b al sistema IPSP comercial 3b 1 (etapa S417) . Asumiendo que la respuesta comprende la confirmación del paqo que se ha autorizado, en la etapa S419, el sistema IPSP comercial 3b envia un mensaje de notificación de éxito de pago al intermediario confiable 10. Este mensaje de notificación de éxito de pago comprende una referencia para la autorización de esquema de tarjeta y un identificádor de transacción para la transacción de esquema de tarjeta. 1 Después que el intermediario confiable 10 envía un i mensaje de confirmación de éxito de pago al sistema comercial le (etapa S421), que incita al sistema comercial a confirmar el estado del pedido al usuario (etapa S243) .
Se apreciará de lo anterior que los sistemas comerciales convencionales (incluyendo su sistema IPSP comercial) requieren la modificación para incluir "Pago de Cuenta Corriente" (PCA) como una opción de pago y en .efecto para interconectarse con el intermediario confiable 10. Por consiguiente, el sistema IPSP comercial expone un servicio de i autorización de pago al 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 intermediario confiable ' 10 se I I 34 integra con muchos sistemas IPSP comerciales, comprende por consiguiente una pluralidad de protocolos y formatos de interfaz, cada uno correspondiente a un sistema IPSP comercial respectivo. Además, cada sistema comercial se configura con componentes de software de integración, por ejemplo en la forma de plugins, lo cual habilita al comercio a integrarse con el intermediario confiable 10 para el propósito de iniciar una transacción de pago usando PCA como un método de pago. ' I Los detalles de las capacidades de procesamiento y i configuración del sistema intermediario confiable 4, referido en la presente como PCA, ahora serán descritos con referencia a la Figura 5a. Después, los detalles del intermediario confiable 10, referido como "Sistema Seguro para Pago^' (SSP) y en el cual el sistema intermediario confiable1 4 es implementado muy convenientemente, se describirán con referencia a la Figura 5b.
El sistema intermediario confiable 4 comprende componentes de procesamiento de conectividad y presentación 504, los cuales se configuran para transmitir y manejar varios datos específicos del comercio y banco; 1 estos componentes de procesamiento serán explicados con más detalle j posteriormente, pero en la revisión general comprenden lo siguiente: i I 35 ! i I Almacén de datos del banco: , El sistema intermediario confiable 4 almacena identificadores de banco, por ejemplo en la forma de Códigos de Identificación de Banco (BICs) , o nombres de pais, marca y banco, para aquellos bancos emisores que han contratado el servicio "Pago de Cuenta Corriente" (PCA) . Para cada banco emisor listado, la base de datos DB1 también mantiene datos que identifican una URL correspondiente a su página de registro de banca en línea.
I 1 i Almacén de ciatos de comercio: ¡ El sistema intermediario confiable 4 almacena datos de registro y perfil de comerciante. Estos datos incluyen un identificador de cuenta de comercio junto con un i identificador de red y de transacción del sistema IPSP i comercial 3b con el cual el sistema comercial se registró. Estos datos se mantienen para habilitar al sistema intermediario confiable 4 para comunicarse con el sistema IPSP comercial 3b en beneficio del sistema comercial en la manera descrita anteriormente, 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 4 comprende un servicio de autorización de pago a través del cual el sistema intermediario confiable 4 efectúa los pagos en beneficio del I 36 ¡ I comercio. Además, debido a que el sistema intermediario confiable 4 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. Por consiguiente, los datos de transmisión mencionados antes comprenden un mapeo de una solicitud de autorización de pago que emana de un isistema comercial en linea dado a un identificador de IPSP, una dirección de red y/o protocolos de red que habilitan las i 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 PCA involucra el comercio que especifica al sistema IPSP comercial cual suscribir. Convenientemente, el sistema intermediario confiable 4 puede mantener un conjunto de registros correspondientes a sistemas IPSP comerciales activos: cada conjunto de registros puede comprender identificador dé red y protocolos de comunicaciones requeridos para almacenamiento en la base de datos DB1 por el sistema intermediario confiable 4. Por consiguiente, durante el registro con el sistema intermediario confiable 4 el comercio en linea dado puede seleccionar, por ejemplo, via una lista desplegable coordinada por los componentes de presentación 5(34 del I 37 sistema intermediario confiable 4, 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 cpmercio mantenidos 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 sistema I intermediario confiable 4 puede realizar una consulta adecuada de la base de datos y recuperar el identificador de red correspondiente, requerimientos de protocolo, etc. del sistema IPSP comercial correspondiente. j Adaptador de servicios de Interfaces de Programación de Aplicación (API) El sistema intermediario confiable 4 comprende un Adaptador de Servicios API , el cual habilita la conectividad entre el sistema intermediario confiable 4 ! y la infraestructura de mensajería del sistema de pago 1. El adaptador se configura para manejar el cumplimiento de las solicitudes del sistema intermediario confiable 4 a servicios externos, tales como autorizaciones de pago al sistema IPSP comercial 3b y para exponer un conjunto de los servicios del sistema intermediario confiable 4 que se podrá usar por 38 funciones externas tal como el sistema IPSP comercial 3b.
Datos y componentes específicos de la transacción: El sistema intermediario confiable 4 almacena datos de transacción tales como autorizaciones de pago y estados de cuenta que se manejan por el sistema intermediario confiable 4. Además, el sistema intermediario confiable 4 puede almacenar datos de auditoria asociados con la actividad en linea del comercio así como también actividad de sistema general. , Se señalará que los componentes mencionados antes no incluyen medios para almacenar datos específicos del usuario; esto es porque el usuario especifica el método de i pago en tiempo real (es decir en el punto que se efectúa una transacción) y porque el usuario es autenticado para el servicio de pago por su banco en línea. Por consiguiente, el sistema intermediario confiable 4 no necesita mantener datos específicos del usuario. Sin embargo, esto se entenderá que es un aspecto opcional de la invención: el sistema intermediario confiable 4 podrá, y en efecto en algunas modalidades (tales como aquellas descritas posteriormente con referencia a la Figura 11) se requiere, almacenar credenciales del usuario. En efecto cuando un usuario opta por hacer uso de la funcionalidad alternativa proporcionada por el intermediario confiable 10 (referido posteriormente I í I ¡ 39 I como servicio WSSP"), los datos de usuario serán recibidos y mantenidos por este. La funcionalidad asociada por el intermediario confiable 10 se describe posteriormente con referencia a la Figura 5b. ' Remanente con el arreglo mostrado en la figura 5a, y como se mencionó anteriormente, el sistema intermediario confiable 4 preferiblemente se incluye como un servidor de aplicación web, por ejemplo como un servidor de aplicación compatible J2EE 501 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 503, el cual actúa como el punto de I entrada para las solicitudes externas de HTTP al sistema i intermediario confiable 4 desde comercios y de buscadores de usuarios . 1 El servidor web y motor servlet 503 comprenden componentes de presentación, los cuales exponen envoltorios de API o APIs de pago basadas en servicios web a los sistemas comerciales. Además, el servidor web y motor servlet 503 comprenden los componentes de procesamiento de presentación 504 mencionados antes los cuales se configuran para generar y manejar la interfaz a comercios y bancos como se describe anteriormente. 1 El Servidor de Aplicación J2EE 501 maneja toda la lógica de negocios para las aplicaciones y plataforma web. La lógica de negocios comprende componentes de software 40 funcionales 511a, 511b, los cuales se pueden implementar, por ejemplo, como EJBs (Java Beans Empresariales) de Sesión. Estos grupos funcionales incluyen, por ejemplo, lógica de servicios de pago, y módulos de servicio de seguridad y contra fraude; además el servidor 501 comprende objetos implementados como objetos Java específicos de EJB 3.0 511a, i 511b que proporcionan acceso a datos persistentes y estáticos almacenados en la DB1 tales como datos de auditoría y datos de transacción descritos anteriormente. El sistema i intermediario confiable 4 adicionalmente comprende servicios i web en la forma de envoltorios que exponen los EJBs de iSesión a otros elementos del sistema de pago 1. Más específicamente, los componentes funcionales 511f, 511g interoperah con habilitadores de servicio externos tales como servicios contra fraude 515a, entre otros. Estos componentes del servidor de aplicación 511f, 511g se comunican co,n los componentes de aplicación vía un conjunto de APIs, referidos genéricamente, tal como con relación a la parte 513a. Cuando se implementan como un servidor web, los datos entre los elementos del sistema de pago 1 (es decir, aquellos mostrados en las Figuras 3 y 4) y el sistema intermediario confiable 4 se transmiten usando un mecanismo seguro, por ejemplo vía el HTTP sobre el protocolo de Capa de Conexión Segura (HTTPS) .
Como se mencionó anteriormente, además de coordinar la selección de cuenta por el usuario Ul en la manera I i 41 descrita anteriormente, y por consiguiente incorporando el sistema intermediario confiable 4, el intermediario confiable 10 incluye la funcionalidad que habilita al usuario Ul para seleccionar de una pluralidad de cuentas pre-configuradas en adición, o como una alternativa, especificar una cuenta de transacción en una base por transacción. Esta funcionalidad se vuelve disponible a un usuario vía un servicio referido en la presente como "Sistema Seguro de Pago" (SSP) . Como se describirá con más detalle posteriormente, la base de datos i DB1 puede mantener un conjunto de detalles de pago para el usuario en la forma de un conjunto de registros almacenados convenientemente referidos como un almacén remoto, o cartera de usuario; los usuarios pueden añadir detalles de tarjetas y cuentas que pueden seleccionar para hacer el pago de una transacción, causando que el intermediario confiable 10 actualice los contenidos de la cartera del usuario. Esto hace posible que el usuario seleccione un método de pago ; en una base por transacción, mientras se remueve el requerimiento que el usuario proporcione detalles de pago a comercios individuales. Por consiguiente, siempre que los comercios proporcionados se suscriben al intermediario confiable 10, los usuarios solamente tienen que presentar sus detalles de pago respectivos una vez, a una entidad única. Esto tiene el beneficio de reducir el riesgo que se puede incurrir con relación a los sistemas de pago convencionales que requieren 42 que el usuario Ul ingrese sus detalles de pago con tarjeta via el sistema del comercio. 1 También como se describió anteriormente, el intermediario confiable 10 se conecta a sistemas de banco emisor 2a, 2b. Esta conexión facilita la verificación del titular de la tarjeta (comprador) cuando se añade un instrumento de pago a su cartera usando el mecanismo de autenticación 3-D Secure 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 un instrumento de pago . se añade a la cartera del usuario, o cuando el intermediario confiable 10 determina que una transacción solicitada dada corresponde a un nivel de riesgo predeterminado, tal como puede ser el caso para transacciones que involucran envío al extranjero de mercancías de alto valor, etc. 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 43 describe con más detalle posteriormente.
El sistema de esquema de tarjeta 7 se conecta comunicativamente al intermediario confiable 10 como se muestra esquemáticamente por la linea de puntos L3; esto í indica que el intermediario confiable 10 se ha suscrito a un servicio de actualización de cuentas (no etiquetado) en la Figura 3, pero descrito con referencia a la Figura 5b j posterior como parte 515d) proporcionado por el sistema de esquema de tarjeta 7 y por lo tanto recibe información de i tarjeta actualizada, por ejemplo cuando una tarjeta se I 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 I de cuentas proporcionado por el sistema de esquema de tarjeta 7 es orientado por lote: el 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 I típicamente se usa (por ejemplo, Protocolo de Transferencia Segura de Archivos (SFTP) o Connect : DirectÍTM) ) para enviar los i archivos de solicitud al servicio de actualización de i cuentas, el cual es responsable de otorgar los detalles de las tarjetas reemitidas. Después de un intervalo el I 44 j I intermediario confiable 10 ingresa al servicio de i 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 I alternativa a enviar la solicitud directamente al sistema de esquema de tarjeta 7, el intermediario confiable 10 podrá i 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.
La Figura 5b es una ilustración esquemática de componentes del intermediario confiable 10. Puesto que, en I este arreglo, el sistema intermediario confiable 4 se incluye dentro del intermediario confiable 10 usando tecnología de i servidor web, en una modalidad el intermediario confiable 10 también es un servidor web. Para proporcionar el servicio SSP, el intermediario confiable 10 comprende los siguientes elementos: | I I Datos y componentes de registro del usuario ' Cuando un usuario desea hacer uso de la facilidad de instrumento de pago pre-almacenado ofrecida por el i 45 intermediario confiable 10, se requiere que se complete un proceso de registro de cuenta que permite al usuario crear i una cuenta de "Sistema Seguro de Pago" (SSP) . La cuenta se requiere que sea poblada con datos apropiados que se ' pueden usar para hacer pagos vía el servicio SSP de un sistema comercial que ofrece el servicio SSP como una opción de pago. i El registro del usuario con el intermediario confiable 10 se puede realizar vía cualquier ihterfaz adecuada, más convenientemente, cuando el intermediario confiable 10 se implementa como un servidor web, vía un ? buscador web. Una vez registrado, cada usuario tiene un perfil asociado con este, el cual almacena datos de identificación y demográficos del usuario y se ^ pueden modificar vía los componentes de presentación 504, mientras que los datos de transacción de usuario se pueden visualizar para revisión por el usuario. Además el usuario puede tener entradas de libreta de direcciones, las cuales mantienen detalles de envío; los componentes de presentación 504 habilitan al usuario para modificar los detalles de 'envío. Como se muestra en la Figura 5b y se explica con más detalle posteriormente, en el caso donde el intermediario confiable 10 se implementa como un servidor web, los componentes de presentación 504 interoperan con el buscador del usuario para permitir la selección y modificación de los datos de usuario en la manera apenas descrita.
El registro se puede efectuar vía un número de Vía sitio de "Sistema Seguro de Pago" (SSP!) - el usuario se registra en el sitio web del intermediario confiable 10 y se presenta con una página de registro diseñada para capturar los i detalles de pago preferido e identidad del usuario Redirección desde el pago - Si el usuarib está dentro del sistema en línea del comercio y desea pagar usando la opción "Sistema Seguro de. Pago" (SSP) necesitará registrar si no lo ha hecho. El cliente es redirigido a las pantallas de registro asociadas con el intermediario confiable 10 y luego redirigido de nuevo al sistema en línea del comercio. , Registro vía banco en línea - asumiendo que el intermediario confiable 10 comprende la funcionalidad de integración necesaria, el usuario puede registrarse para el servicio de "Sistema Seguro de Pago" (SSP) dentro de su manejo de ¡cuenta en línea del banco.
Componentes de autenticación del usuario: La autenticación de un usuario en el servicio SSP para transacciones de pago se puede realizar directamente con 47 el intermediario confiable 10 de acuerdo con cualquiera de las 3 categorías conocidas listadas posteriormente, o vía el I banco en línea del usuario, en este caso el usuario ingresa en su cuenta de banca en línea (usando una de la's tres categorías listadas posteriormente), en donde el software de sistema de banca redirige al usuario de nuevo al t intermediario confiable 10. factor de autenticación 1 - Algunas veces el usuario i 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, I 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 48 i banco y el comprador. Puesto que el comercio no conoce esta contraseña y no es responsable de capturarla, se puede usar 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 ¡ podría iniciar sesión en su cuenta bancaria en línea, en donde el software del sistema bancario podría 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 específica 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. i Datos de cuenta del usuario: Como se mencionó anteriormente, los usuarios pueden tener un conjunto de registros, por ejemplo en la forma de un almacén remoto, o cartera, asociado con este, el' cual almacena los detalles de los instrumentos de¦ pago introducidos por el usuario y cuyos detalles se ^desean almacenar en una manera permanente para la recuperación y 49 acceso vía el intermediario confiable 10. Los componentes de presentación 504 habilitan al usuario para seleccionar y añadir/remover de la lista de instrumentos de pago.
I Datos y componentes específicos de la transacción: Además de almacenar datos de auditoria asociados con la actividad en linea del comercio, el intermediario confiable 10 puede almacenar datos de actividad del usu rio.
Servicios de Mensajería El 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.
El servidor web y motor servlet 503 comprenden componentes de presentación, los cuales exponen envoltorios de API o APIs de pago basadas en servicios web 506 a los sistemas comerciales. ! Además de los componentes de lógica de negocios 511f, 511g descritos anteriormente, el Servidor de Aplicación J2EE 501 comprende componentes de software funcionales 511c ... 511e los cuales interoperan con habilitadores de s rvicio externos 505 tales como servicios de validación de dirección i 515a, aplicaciones de correo electrónico (incluyendo acceso a 50 un servidor de correo electrónico) 515b, servicios 3-D Secure 515c, servicios de actualización de cuenta 515d, y servicios contra fraudes 515e, entre otros. Consistente con el ¡arreglo mostrado en la Figura 5a, los componente de servidor de aplicación se comunican con los componentes de aplicación 515a ... 515e vía un conjunto de APIs, referidos genéricamente, tal como con relación a las partes 513a ... 513e. ' En el caso del componente funcional de servicio 3-D Secure 511c, este componente usa, o coopera .con, reglas basadas en riesgo que se invocan 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 515e, 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) 511d y servicio correspondiente 515d proporcionado por el sistema de esquema de tarjeta 7, el componente de AU 51Id 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 I especificada. El componente de AU 51Id posteriormente accede al servicio de actualización de cuenta 515d y colecta un archivo de respuesta generado, y actualiza los instrumentos de pago en las carteras de usuario relevantes sobre ía base del contenido del archivo de respuesta. 1 Las etapas de procesamiento descritas anteriormente con referencia a la Figura 4, específicamente las etapas realizadas por el sistema intermediario confiable 4 para hacer posible que el usuario seleccione una cuenta de transacción para pago de acuerdo con una primera modalidad de la invención, ahora serán descritas con más detalle. Regresando a la Figura 6, en la etapa S6.1, el usuario selecciona "Pago de Cuenta Corriente" (PCA) como el métlodo de pago y presenta su selección al sitio web del comercio!. Esto activa una solicitud del sistema comercial, específicamente 52 ? la recuperación por el sistema comercial de la URL correspondiente al servicio PCA del intermediario confiable 10. Esto resulta en que el sitio web del comercio recarga su página de pago con un iFrame, el contenido del cual corresponde a la URL de PCA, y posteriormente el envío de una orden clave y la creación de una sesión segura etapa ;S 6.3). Habiendo recibido la URL de PCA del intermediario confiable 10, el usuario Ul selecciona el Código de Identidad de Banco (BIC) introduciendo identificadores de banco tales como país, banco y marca (etapa S6.5). La selección luego se transmite a la aplicación web de sistema intermediario confiable 501 (etapa S6.7), activando la aplicación 501 para verificar que el banco seleccionado es un participante del servicio PCA (etapa S6.9). Asumiendo que este sea el caso, el sistema intermediario confiable 4 recupera la URL de la página de inicio de sesión del banco de los datos almacenados en la base de datos DB1 y envía esta al iFrame (etapa S6.ll), causando que el buscador del usuario dirija al usuario a su página web de banca en línea (etapa S6.13). Se señala que el usuario iniciando sesión en su cuenta de banca en línea sirve para autenticarlo al sistema intermediario confiable 4 - es decir no hay necesidad de un segundo proceso de autenticación con la entidad de procesamiento de pago intermedia 10.
El usuario Ul luego ingresa sus detalles de banca en línea (etapa S6.13); asumiendo que el registro es exitoso, 53 i el software de banco activa un token de auto-vencimiento (etapa S6.15). El token se puede usar para cualquiera de las llamadas de API como prueba de autenticación, ¡ y por consiguiente se regresa al iFrame, junto con una instrucción para redirigir el iFrame de nuevo al sistema intermediario confiable 4 (etapa S6.17). La instrucción de redirección j activa un mensaje de solicitud para ser enviado; a la aplicación de sistema intermediario confiable 4, instruyendo a la aplicación de sistema intermediario confiable 4 j solicitar una lista de cuentas del usuario (etapa S6.19) del software de banca. Por consiguiente, una llamada de API al software de banca en linea se hace para obtener la lista de I cuentas y PANs, usando el token de autenticación transmitido al sistema intermediario confiable 4 en la etapa S6.17 (etapa S6.21) . Después, una lista de cuentas se envía a la aplicación de sistema intermediario confiable 4 (etapa S6.23), que generar una página de selección de cuenta para exhibir al usuario (etapa S6.25), habilitando al usuario para seleccionar una cuenta y presentar su selección ¡ a la aplicación de sistema intermediario confiable 4 (etapa S6.27) . La aplicación de sistema intermediario confiable 501 luego transmite la selección de cuenta al software dé banca emisora, de nuevo usando el token de banco (etapa S6.29), junto con una solicitud de identificador de cuenta correspondiente a la cuenta seleccionada. En respuesta el i I i 54 I software del banco regresa el número PAN normalmente asociado con la tarjeta de débito enlaza a la cuenta del usuario a la i aplicación de sistema intermediario confiable 4 (etapa S6.31). 1 Habiendo recibido el PAN, el servidor web y motor servlet 503 envían los detalles del pago al sistema IPSP j comercial del comercio 3b vía un servicio de autorización de pago a través del cual el intermediario confiable 10 efectúa la presentación de una solicitud de pago en beneficio del comercio; esto involucra crear una solicitud de autorización para la recepción por las APIs de pago 506, convirtiendo la solicitud de autorización de pago en el formato API de !la API del comercio y transmitiendo la solicitud formateada al i sistema IPSP comercial 3b. Una solicitud de liquidación también se transmite a las APIs de pago 506, que reaíiza la conversión de la solicitud de liquidación en el formato API de la API del comercio y transmite las mismas al sistema IPSP comercial 3b. Se apreciará que la comunicación se puede efectuar por implementaciones de mensaje ya sea único o1 dual. Estas acciones de formateo y transmisión se registran] en el almacén de datos de transacción mantenido por el intermediario confiable 10 correspondiente al sistema comercial.
En la notificación de la autorización de la solicitud de pago, el servidor web y motor servlet 503 55 ? transmiten una URL de comercio de retorno al iFrame, junto con la notificación de autorización exitosa, causando , que el i iFrame se vacie, recargue con código Javascript del sistema comercial, y por consiguiente remueva el iFrame y regrese al usuario al sitio web del comercio. Finalmente, el comercio exhibe la página web de de pago exitoso. ! El proceso mostrado en la Figura 16 es particularmente ventajoso porgue el usuario se presenta con su propia página de inicio se sesión de marca de banco; i además el banco porta solo la responsabilidad de autenticar al usuario, y por lo tanto puede aplicar sus propios campos y métodos de autenticación. Además, debido a que el software del banco envía un token al iFrame de sistema intermediario confiable, y este se pasa a la aplicación de sistema intermediario confiable 501, habilitando a la aplicación de sistema intermediario confiable a iniciar una sesión de comunicación con el banco emisor, el usuario se presenta con una interfaz estandarizada para recuperar los identificadores de cuenta e identificadores de cuenta asociados de su banco.
En paralelo con las etapas anteriores, el servidor de aplicación 501 puede registrar la actividad del usuario y enviarla al almacén de datos de auditoría, mientras envía la información de evento y sistema correspondiente a un sistema I de notificación de fraude de terceras partes (se representa I por uno de los habilitadores de servicios comunes 515a j i I I 56 mostrados en la Figura 4). El sistema de notificación de fraude comprende, pero no se limitan a, un motor de riesgo de fraude, el cual realiza el análisis del mismo para genérar un registro de riesgo y una acción recomendada para la 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 y el usuario.
Se contemplan métodos alternativos para habilitar al usuario para seleccionar una cuenta de su banco pmisor: los ejemplos de tales métodos alternativos se muestran en las I Figuras 7-10. La Figura 7 difiere de la modalidad mostrada en la Figura 6 porque el banco emisor envia una URL de selección de cuenta en respuesta al usuario que ha presentado sus detalles de registro, causando el rendimiento de cuenta del usuario bajo control directo del software de banca antes que vía una API ofrecida por el software de banca. Por consiguiente, las etapas 7.1-7.13 proceden por las etapas 6.1-61.3, entonces en la etapa 7.15 el software de banca envia una URL de selección de cuenta al iFrame del sistema intermediario confiable cargado en el sitio web del comercio, una ves visualizada, el usuario puede seleccionar una cuenta i de aquellas listadas (etapa 7.17), en donde la cuenta 57 seleccionada se presenta al software de banca (etapa 7.19) y el número PAN correspondiente a la cuenta seleccionada se transmite a la aplicación de sistema intermediario confiable (etapa 7.21).
La Figura 8 muestra un arreglo en el cual las interacciones entre el sistema intermediario confiable 4 y el banco emisor se han pasado a una tercera parte tal como RSA(TM> o Arcot'™1: la tercera pare proporciona los servicios en beneficio de bancos emisores. Las etapas 8.1-8.9 proceden por i las etapas 6.1-6.9; en la etapa 8.11 el sistema intermediario confiable 4 identifica los bancos registrados en URL como hospedados por la tercera parte de sus datos de configuración, y los visualiza en el iFrame. El usuario posteriormente ingresa sus detalles de registro, los cuales se transmiten a la tercera parte (etapa 8.13). En respuesta, el servicio de hospedaje de tercera parte crea un token de auto vencimiento para cualquiera de las llamadas de API subsecuentes (etapa 8.14) y envía una URL de selección de cuenta al iFrame para visualizar al usuario en el sitio web del comercio. Las etapas 8.15-8.21 proceden como se describió con referencia a las etapas 7.15-7.21 de la Figura 7. t La Figura 9 muestra un arreglo en el Cj al el usuario proporciona sus detalles de banca en línea al ¡sistema intermediario confiable 4, el cual posteriormente ¡usa la información de registro para iniciar sesión automáticamente en el banco emisor y por lo tanto recuperar la lista de cuenta. En este arreglo la aplicación de sistema intermediario confiable 503 actúa como un mediador entre el sistema comercial en línea y el banco emisor. Las etapas 9.1-9.11 proceden como se describió con referencia a la Figura 6, pero en la etapa 9.13 los detalles de registro se envían a la í aplicación de sistema intermediario confiable 503, la cual recupera la URL de registro de banco, pobla la misma con los detalles de registro del usuario recibidos en la etapa 9.13, y realiza el registro al software de banca en línea en í beneficio del usuario (etapas 9.15, 9.17). Los núméros de cuenta luego se transmiten a la aplicación de ¡sistema intermediario confiable 503 (etapa 9.19a), la cual transmite los mismos al iFrame junto con la notificación de inicio de sesión exitoso (etapa 9.19b). La página de selección de cuenta se visualiza en el iFrame (etapa 9.21) y la selección de cuenta de usuario se transmite a la aplicación de sistema intermediario confiable 503 para transmisión posterior al servidor web del banco emisor (etapas 9.23, 1 9.25) . Finalmente, el PAN se envía desde el servidor web emisor a la aplicación de sistema intermediario confiable 503 (etapa I 9.27) . ! La Figura 10 muestra un arreglo en el cual luna API se usa por la aplicación de sistema intermediario confiable 503 para recuperar la lista de cuentas del software de banca.
I í 59 i Según la modalidad de la figura 9, se requiere que el usuario primero seleccione su banco, en donde la aplicación de sistema intermediario confiable 503 proporciona una página de registro para que el usuario ingrese sus detalles de registro de banca en linea. Luego se hace una llamada al banco emisor para recuperar la lista de cuentas para la información registrada proporcionada por el usuario. Con más detalle, las etapas 10.1-10.13 proceden como se describió con referencia a la Figura 6, luego en la etapa 10.15, y en respuesta a la recepción de los detalles registrados del usuario, el software de banco emisor genera un token de autenticación, el cual posteriormente se transmite al iFrame del sistema intermediario confiable 4 (etapa 10.17). En respuesta, el sistema intermediario confiable 4 envía una solicitud 'de una lista de cuentas correspondiente al usuario (autenticado en la etapa 10.15), la solicitud se acompaña por el token de autenticación. Asumiendo que el token de autenticación se iguala a aquel generado en la etapa 10.15, la lista de cuentas se envía a la aplicación de sistema intermediario 503 (etapa 10.19a), la cual temporalmente almacena las quentas (incluyendo los identificadores de cuenta) y coordina la visualización de las mismas en el iFrame en el sistéma en línea del comercio (10.19b). Por consiguiente, cuando el I · usuario selecciona una cuenta de la lista (etapa 10.21), esto resulta en que la aplicación de sistema intermediario 503 60 1 i identifica el PAN correspondiente de los números almacenados I en su propio almacenamiento temporal y local . i Como una alternativa adicional, el usuario podrá ser autenticado por el intermediario confiable 10 y delegar la responsabilidad al intermediario confiable 10 para efectuar un inicio de sesión en la cuenta de ' banco seleccionada del usuario. El inicio de sesión sei puede realizar sobre la base de un conjunto adecuado de credenciales suministradas por el usuario, tal como un| número de tarjeta de crédito y/o fecha de vencimiento, el cual el I usuario podrá introducir en tiempo real o seleccionar de sus detalles de tarjeta almacenados, y que forma la base de la autenticación del usuario por el banco emisor seleccionado. i La Figura 11 es un diagrama de flujo genérico que muestra las etapas involucradas al efectuar el paso usando un instrumento de pago seleccionado de acuerdo con una modalidad de la invención bajo control del servicio "Sistema Seguro de Pago" (SSP) : en la etapa Sll.l el usuario selecciona la opción "pagar y registrar" del software de compras en linea i del comercio, en donde se requiere que primero el usuario I cree una cuenta SSP proporcionando información personal tal como nombre, dirección de correo electrónico, una contraseña, número telefónico de contacto, cualquier dirección de posible entrega (etapa Sil.2) . Estos detalles se guardan en la base de datos, y el usuario luego se presenta con dos opciones: ya i I í 61 i sea pagar con tarjeta o pagar de una cuenta corriente. La ramificación etiquetada como etapa 11.3a corresponde genéricamente a las etapas de proceso descritas con referencia a las Figuras l-5a, 6-10, mientras que la etapa 11.3b corresponde al usuario que selecciona la opción de ingresar y almacenar detalles de una tarjeta que se usa para la transacción. Esta última alternativa por lo tanto hace uso de la funcionalidad SSP del intermediario confiable 10 descrita con referencia a la Figura 5b, con los componentes de presentación 504 proporcionando al usuario con una interfaz para ingresar detalles de la tarjeta y por lo tanto almacenar los mismos en la base de datos DB1. Como se i mencionó anteriormente, el componente 3-D Securé 511c preferiblemente se invoca cuando el usuario ingresa detalles de la tarjeta específicos para almacenamiento en su Cartera y/o en respuesta a ciertos eventos de transacción.
Sin considerar la opción de pago seleccionada, el usuario luego es incitado a verificar que sus detalles de transacción son correctos, o agregarlos/editarlos por ejemplo, proporcionando una dirección de entrega alternativa. El usuario luego puede finalizar la transacción. Una vez que el proceso de selección de pago se ha completado, el intermediario confiable 10 procede con la transacción bomo se describió, por ejemplo, con referencia a las etapas S413-S421 de la Figura 4, finalizando el proceso con la transmisión de 62 un mensaje de confirmación al comercio en linea.
De lo anterior se apreciará que las modalidades de la invención se pueden ver que comprenden varias partes, principalmente a) invocación; b) autenticación; c) selección de cuenta; y d) enrutamiento del pago. Con respecto a la parte a) , la opción "Pago de Cuenta Corriente" (PCA) se puede invocar ya sea directamente del sitio web del comercio en línea, como se describió con referencia a las Figuras 1-8, o vía el servicio "Sistema Seguro de Pago" (SSP) , como se describió con referencia a la Figura 11. ¡ Con relación a la autenticación de la solicitud del usuario para seleccionar una cuenta para pago, se puede realizar bajo control del banco emisor seleccionado, usando la información mantenida por el banco del usuario (Figura 1-8), o bajo control del intermediario confiable 10, que puede involucrar · opcionalmente un proceso de registro (Figura 11). En cualquier caso se apreciará que no existe requerimiento de registro como tal con el intermediario confiable, puesto que el usuario es autenticado efectivamente en el inicio de sesión exitoso en su cuenta de banco en linea.
Con relación a la selección de una cuenta para pago, un usuario puede tener una pluralidad de cuentas dentro de un banco emisor dado y en efecto puede tener cuentas con una pluralidad de bancos emisores. Por consiguiente, la interfaz presentada al usuario, si se dirige desde el ¡sistema 63 i del comercio en linea, o vía el servicio SSP, es tal! que el usuario puede identificar su banco emisor elegido y en1 efecto las cuentas de banco en este. Cuando es autenticado por el i banco emisor, el banco presenta una lista de cuentas al usuario, el usuario selecciona y envía los detalles de la cuenta de banco al servicio PCA. Cuando es autenticado por el servicio SSP, el servicio SSP presenta una lista de cuentas, i con base en los datos previamente guardados, para la selección por el usuario. i Regresando finalmente al enrutamiento de pago, como se describió con referencia a las Figuras 1-10, una transacción se puede efectuar usando el PAN suministrado vía el sistema IPSP comercial asociado con el comprador. Como una alternativa, la transacción podrá ser cargada a la cuenta del usuario y acreditada a la cuenta de comercio vía un sistema de esquema de tarjeta o un sistema de banco adquisidor. Como una alternativa adicional, la transacción se podrá cargar de la cuenta del usuario vía una clave de cuenta alternativa y acreditar a la cuenta de comercio vía una clavé de ¡ cuenta alternativa. 1 Las modalidades anteriores se entenderán1 como ejemplos ilustrativos de la invención. Se contemplan modalidades adicionales de la invención. Por ejemplo, i mientras que en los ejemplos anteriores el intermediario confiable 10 se describe recibiendo solicitudes de pago de í I I 64 sistemas comerciales en linea, el intermediario confiable 10 adicionalmente o alternativamente podrá recibir solicitudes de pago de un sistema IPSP comercial en un arreglo en jel cual el sistema IPSP comercial está proporcionando servicios de pago al usuario. En tales modalidades, los sistemas IPSP comerciales se modifican para ofrecer "Sistema Seguro de Pago" (SSP) como una opción de pago adicional.
Mientras que en las modalidades anteriores, la identidad de cuenta financiera se da en la forma de un PAN, otras identidades de cuenta financiera se pueden usar en la alternativa. Por ejemplo, un Número de Cuenta de! Banco Internacional (IBAN) del usuario, o alternativamente un identificador de banco, el cual preferiblemente es un identificador de banco internacional tal como código de país y código de clasificación, o código IB, y un número de cuenta. Sin embargo, un formato PAN se prefiere puesto que j está en el formato el cual se procesa usando pagos de esquema de tarjeta existentes.
Mientras que en las modalidades anteriores, se usa un PAN permanentemente asociado con una cuenta financiera del usuario, en la alternativa, o en adición, un sistema dé banco emisor puede proporcionar, como respuesta de identificador de cuenta, PANs de uso único los cuales se generan para uso único, y un número grande de tales PAN de uso único se puede almacenar y mapear por el sistema de banco emisor contra una 65 I cuenta financiera única .
I Además, en los ejemplos anteriores se asume que el punto de partida para el proceso es el sitio web del comercio en línea; sin embargo modalidades de la invención también se j podrán usar en conjunto con efectuar pagos de facturas u otras cuentas, donde el origen de la transacción podría no ser un sistema comercial en línea. Los escenarios de tipo de I pago de factura tradicionales asumen un pago forzoso del comprador (usuario) al beneficiario, típicamente a través de la Cámara de Compensación Automatizada (ACH) , de modo que el pago se inicia en este escenario desde un punto de partida diferente de un sistema comercial, la transacción financiera actual no obstante se ingresa en el ambiente de procesamiento de transacción por un agente del comercio. En consecuencia, en términos financieros se podría considerar un pago f rzoso; sin embargo, puesto que el pago se inicia por el comprador (el pagador), el usuario lo percibirá como un pago forzoso.
Además, mientras que las modalidades preferidas i hacen uso de la tecnología web iFrame para hacer que el usuario navegue a diferentes sitios web, se apreciará I 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 al sitio web del sistema intermediario confiable 4, dependiendo de la entidad (o más bien la URL i correspondiente a este) con la cual el buscador del usuario 66 está comunicado en cualquier punto temporal. Por e'jemplo, 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 i 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 lo anterior, el término "sistema", cuándo se aplica a entidades tales como el sistema comercial, el sistema IPSP comercial, el sistema intermediario confiable, el sistema de identificación de cuenta y otras entidades, se deberá entender que significa una función de procesamiento de datos, proporcionada 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. 67 I Como se apreciará de lo anterior, las comunicaciones entre las diversas entidades que comprenden el sistema de pago 1 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 sistema de identificación de cuenta dentro del banco emisor, el cual se usa para identificar una cuenta corriente de la cual él pago será deducido; el sistema intermediario confiable; el intermediario confiable; el procesador de banco adquisidor; los sistemas IPSP comerciales; y los sistemas comerciales en linea) es identificable via un identificador de red tal como una dirección de Protocolo de Internet (IP) u otro i identificador adecuado.
Por consiguiente, la red de comunicaciones puede comprender una red de linea fija que comprende una, o más tecnologías, es decir una 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 de comunicación: GSM (Sistema i 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 68 BlueTooth® (BT) y/ü otras tecnologías tal como WiMax se pueden usar para portar parte de los mensajes de respuesta y solicitud. 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 (Servkcio de Mensajes Cortos), mensajes MMS (Servicio de Multimedia), páginas de Protocolo 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) .
Una de las modalidades descrita anteriormente se refiere a la aplicación de la invención con relación a una cuenta de banco que tiene una tarjeta asociada con esta; otros no requieren que la cuenta de banco esté asocijada con un producto de pago de cualquier tipo, mientras que otros aún pueden involucrar una cuenta de banco asociada con un producto de pago tal como una información biométrica o I teléfono móvil. Se contemplan otras aplicaciones. '¦ Se entenderá que cualquier característica descrita con relación a cualquier modalidad se puede usar sola, o en 69 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 (37)

70 I REIVINDICACIONES ' i i
1. Un método de procesamiento de solicitúdes de autorización de pago para transacciones de pago que se conducen vía una red de comunicaciones de datos, las i solicitudes de autorización de pago se conducen como un i resultado de pedidos por titulares de cuentas financieras vía una pluralidad de diferentes sistemas comerciales en línea, en donde los titulares de cuentas financieras i mantienen cuentas con una pluralidad de diferentes bancos emisores, caracterizado porque el método comprende conducir un procedimiento de identificación de cuenta que comprende: identificar, de la pluralidad de diferentes j bancos emisores, un banco emisor asociado con un titular de cuentas financieras; 1 sobre la base de la identificación del; banco emisor, recuperar los datos de transmisión de banco ; emisor para habilitar la transmisión de datos de solicitud de identificación de cuenta, los datos de transmisión de banco emisor son dependientes del banco emisor identificado e identificar un sistema de identificación de ' cuenta seleccionada asociado con el banco emisor identificado;1 i sobre la base de los datos de transmisión de banco emisor recuperados, transmitir una solicitud de identificación de cuenta para uso en la autorización de al menos una transacción de pago, al menos una transacción de pago se inicia como un resultado de que un titular de ¡cuentas financieras conduce al menos un pedido vía al menos unos sistemas comerciales en linea; y recibir una respuesta de identificación de1 cuenta en respuesta a la solicitud de identificación de cuenta, la respuesta de identificación de cuenta identifica una identidad de cuenta financiera capaz de ser usada en al menos unas transacciones de pago.
2. Un método . de conformidad con la reivindicación í 1, caracterizado porque adicionalmente comprende, después de recibir la respuesta de identificación de cuenta: , a) generar una solicitud de autorización de pago que comprende datos de transacción que incluyen: i) una identidad de cuenta financiera que se usa en una transacción de pago por el titular de la cuenta financiera; y ii) una identidad de comercio, asociada con un primer comercio en linea, como el beneficiario de la transacción de pago; y iii) detalles de la transacción incluyendo una cantidad del pago; y b) transmitir la solicitud de autorización de 72 pago generada para el procesamiento subsecuente por un sistema procesador de pago de banco adquisidor responsable del procesamiento de autorizaciones de pago para un banco adquisidor con el cual el! primer comercio en linea se asocia. j
3. Un método de conformidad con la reivindicación 2, caracterizado porque la solicitud de autorización de pago se genera en respuesta a la recepción de la respuesta de identificación de cuenta. j
4. Un método de conformidad con la reivindicación I 3, caracterizado porque comprende generar una pluralidad de solicitudes de autorización de pago incluyendo laj misma identidad de cuenta financiera, y conducir un procedimiento í de identificación de cuenta separado, el cual incluye transmitir una solicitud de identificación de cuenta y recibir la respuesta de identificación de cuenta, antes de la generación de cada una de las solicitudes de autorización de pago .
5. Un método de conformidad con la reivindicación 2 o reivindicación 3, caracterizado porque comprende generar una pluralidad de solicitudes de autorización dé pago incluyendo la misma identidad de cuenta financiera, y para cada una de la pluralidad de solicitudes de autorización de pago, mantener la identidad de cuenta financiera, de modo que solamente un procedimiento de identificación de cuenta único, 73 i el cual incluye transmitir una solicitud de identificación de cuenta y recibir una respuesta de identificación de cuenta, se requiere para todas de la pluralidad de solicitudes de autorización de pago. ¡
6. Un método de conformidad con cualquiera de las reivindicaciones 2 a 5, en donde la red de comunicacibnes de datos comprende una pluralidad de diferentes sistemas Proveedores de Servicio de Pago por Internet comerciales (sistema IPSP comercial) , i cada uno de los sistemas IPSP comerciales se arregla para transmitir solicitudes de autorización de pago a I 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 un banco adquisidor, y cada uno de una pluralidad de comercios en Linea se asocia con uno de la pluralidad de sistemas IPSP comerciales, caracterizado porque el método comprende recuperar datos de transmisión de sistema IPSP comercial 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 de sistema IPSP comercial recuperados, transmitir la solicitud 74 1 de autorización de pago generada al sistema IPSP comercial seleccionado, en 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 autorizaciones de pago para el banco adquisidor con el cual el primer comercio en línea está asociado. ¡
7. Un método de conformidad con cualquiera de las reivindicaciones 2 a 6, caracterizado porque el método comprende recibir una identidad de comercio del , primer sistema comercial en línea, la identidad de comercio incluida en la solicitud de autorización generada se genera sobre la base de la identidad de comercio recibida. j
8. Un método de conformidad con cualquier reivindicación precedente, caracterizado porque el mé'todo se conduce por un sistema intermediario confiable, el| método comprende el sistema intermediario confiable que recibe de los sistemas comerciales en línea responsables para originar solicitudes de autorización de pago para comercios en línea, solicitudes de autorización de pago relacionadas con la autorización de transacciones de pago, las solicitudes de autorización de pago recibidas se inician como un resultado de que los titulares de cuentas financieras conducen un pedido vía los sistemas comerciales en línea. |
9. Un método de conformidad con la reivindicación I 8, caracterizado porque el procedimiento de identificación de 75 cuenta se conduce por el sistema intermediario confiable en respuesta a la recepción de una solicitud de autorización de pago de un sistema comercial en linea. ¡
10. Un método de conformidad con la reivindicación 8 o 9, caracterizado porque el sistema intermediario confiable se arregla para recibir una respuesta de autorización de pago, y en respuesta a esto transmitir una respuesta de autorización de pago al primer sistema comercial i en linea. i
11. Un método de conformidad con la reivindicación i 6 y cualquiera de las reivindicaciones 8 a 10, caracterizado porque el sistema intermediario confiable proporciona una interfaz de registro para comercios en linea por lo cual los I comercios en linea pueden registrar un sistema IPSP comercial con el cual se . asocian, y la etapa de recuperación de datos i de transmisión para habilitar la transmisión de datos de solicitud de autorización de pago al sistema IPSP comercial i seleccionado asociado con el primer comercio en linea se conduce sobre la base del sistema IPSP comercial registrado por el primer comercio en linea. í
12. Un método de conformidad con la reivindicación 11, caracterizado porque el sistema intermediario co fiable se arregla para recibir y procesar solicitud s de autorización de pago para transacciones de pago de un : primer tipo originadas del primer sistema comercial en linea', y en respuesta a esto transmitir una solicitud de autorización de pago generada al sistema IPSP comercial seleccionado, y en donde el sistema IPSP comercial se arregla para recibir y procesar solicitudes de autorización de pago¡ para transacciones de pago de un diferente tipo originadas del primer sistema comercial en linea, las solicitudes de i autorización de pago para transacciones de un diferente tipo no se procesan vía el sistema intermediario confiable.
13. Un método de conformidad con cualquier i reivindicación precedente, caracterizado porque el método comprende recibir datos que indican una selección, ,por el titular de cuentas financieras, entre una pluralidad de tales diferentes cuentas financieras para uso en la transacción de pago, y recuperar una identidad de cuenta financiera sobre la base de la selección indicada. I
14. Un método de conformidad con la reivindicación 13, caracterizado porque comprende proporcionar una Ínterfaz de selección de cuenta para un titular de cuentas financieras por lo cual el titular de cuentas financieras puede seleccionar una identidad de cuenta financiera. ¡
15. Un método de conformidad con cualquier reivindicación precedente, caracterizado porque comprende la etapa de autenticar un titular de cuenta financiera1 y, en respuesta a esto, recuperar una identidad de cuenta i financiera . 77
16. Un método de conformidad con cualquier reivindicación precedente, caracterizado porque la etapa de recuperar los datos de transmisión de banco emisor comprende recuperar una dirección de red para el sistema de identificación de cuenta seleccionada. :
17. Un- método de conformidad con la reivindicación 16, caracterizado porque comprende transmitir la dirección de red recuperada a un titular de cuentas financieras para habilitar al titular de cuentas financieras para acceder al sistema de identificación de cuenta seleccionada, por lo cual el titular de cuentas financieras es capaz de conducir un procedimiento de identificación proporcionando información de identificación al sistema de identificación de ¡cuenta seleccionada. ,
18. Un método de conformidad con la reivindicación 17, caracterizado porque comprende recibir la respuesta de identificación de cuenta del sistema intermediario confiable seleccionado en respuesta a la autenticación del titular de cuentas financieras por el sistema de identificación de cuenta seleccionada.
19. Un método de conformidad con cualquier reivindicación precedente, caracterizado porque la identidad de cuenta financiera comprende un Número de Cuenta Principal (PAN) asociado con el titular de cuentas financieras. 1 i
20. Un método de conformidad con la reivindicación 19, caracterizado porque el PAN comprende un número de tarjeta de pago.
21. Un método para autorizar transacciones de pago conducidas vía una red de comunicaciones de datos, una transacción de pago se conduce como un resultado de un pedido por un titular de cuenta financiera vía un sistema de procesamiento de datos comercial, caracterizado porque el método comprende acceder a los detalles de autenticación de banca en linea almacenados por un proceso de autenticación de banca en linea por lo cual un titular de cuentas financieras es capaz de acceder a una aplicación de banca en linea, la aplicación de banca en linea se relaciona con al menos unas cuentas financieras del titular de cuentas financieras, en donde el método comprende: recibir una solicitud relacionada con la autorización de una transacción de pago, la solicitud se inicia como un resultado de que un titular de cuentas financieras conduce un pedido en un sistema de procesámiento de datos comercial; ! en respuesta a la recepción de la solicitud, conducir un proceso de autenticación de pago en el cual el titular de cuentas financieras proporciona detalles de autenticación correspondientes a los detalles de autenticación de banca en linea almacenados; ' en respuesta a la verificación de los detalles de i I i í 79 autenticación introducidos contra los detalles de í autenticación de banca en linea almacenados, recuperar un número de cuenta principal (PAN) para uso en el procesamiento de pago; ¡ transmitir el número de cuenta principalj (PAN) recuperado a un sistema Proveedor de Servicio de Pagos por ? Internet (sistema IPSP comercial) para uso en la autorización de la transacción de pago. '
22. Un método de conformidad con la reivindicación 21, en donde la aplicación de banca en linea se relacijona con una pluralidad de cuentas financieras del titular de cuentas financieras, y caracterizado porque el método comprende recibir datos del titular de cuentas financieras que indican una selección de una de las cuentas financieras del titular de cuentas financieras para uso en el procesamiento de pago, y recuperar el número de cuenta principal (PAN) sobre la base de la selección indicada.
23. Un método de conformidad con la reivindicación 21 o 22, caracterizado porque el número de cuenta principal (PAN) se genera solamente para uso único.
24. Un método de conformidad con la reivindicación 21 o 22, caracterizado porque el numero de cuenta principal (PAN) es un número de tarjeta de pago. |
25. Un método de conformidad con cualquiera de las I reivindicaciones 21 a 24, caracterizado porque el proceso de 80 ? autenticación de pago se conduce por un sistema de procesamiento de datos de banco emisor.
26. Un método de conformidad con la reivindicación 25, caracterizado porque el método se conduce al ménos en I parte vía un sistema de procesamiento de datos de i procesamiento de transacción, separado del sistema de procesamiento de datos de banca emisora. ,
27. Un método de conformidad con la reivindicación 26, caracterizado porque el método comprende el sistema de procesamiento de datos de banca emisora que transmite el i número de cuenta principal (PAN) recuperado al sistema de procesamiento de datos de procesamiento de transacción en respuesta a la verificación de los detalles de autenticación ingresados, y el sistema de procesamiento de datos de procesamiento de transacción transmite el número de ' cuenta principal (PAN) recuperado a un sistema de procesamiento de I datos de procesamiento de pago.
28. Un método de conformidad con la reivindicación 27, caracterizado porque el método comprende el sistema de procesamiento de datos de procesamiento de transacción que almacena el número de cuenta principal (PAN) , recupera el í número de cuenta principal (PAN) , y transmite el número de I cuenta principal (PAN) recuperado a un sistema IPSP comercial en respuesta a la verificación de los detalles de autenticación introducidos. ¡ 81 i
29. Un método de conformidad con cualquiera1 de las reivindicaciones 21 a 28, caracterizado porque la apl'icación de banca en linea proporciona detalles del historial de transacción para una cuenta financiera del titular de 'cuentas financieras .
30. Un sistema intermediario confiable en comunicación con unos sistemas comerciales en linea y con una pluralidad de bancos emisores, cada uno tiene un sistema de identificación de cuenta asociado con este, caracterizado porque el sistema intermediario confiable se arregla para conducir el procedimiento de identificación de cuenta de un i método de conformidad con cualquiera de la reivindicación 1 a reivindicación 20. I
31. Un sistema comercial en linea en comunicación con un sistema intermediario confiable y una pluralidad de i sistemas IPSP comerciales, caracterizado porque el sistema i comercial en linea se arregla para conducir las etapas del sistema comercial en linea de un método de conformidad con cualquiera de la reivindicación 1 a reivindicación 20.
32. Un sistema IPSP comercial en comunicación con i un sistema intermediario confiable y una pluralidad de i sistemas comerciales en linea, caracterizado porque el sistema IPSP comercial se arregla para conducir las etapas i del sistema IPSP comercial de un método de conformidad con cualquiera de la reivindicación 1 a reivindicación 20. 82 I
33. Un sistema de procesamiento de datos, i caracterizado porque se arregla para conducir el método de conformidad con cualquiera de la reivindicación1 1 a I reivindicación 20. I
34. Un sistema de procesamiento de datos de banca emisora en comunicación con un sistema de procesamiénto de datos comercial y un sistema IPSP comercial, caracterizado porque el sistema de procesamiento de datos de banca emisora se arregla para conducir las etapas de proceso de autenticación de pago de un método de conformidad con I cualquiera de la reivindicación 21 a reivindicación 29.
35. Un sistema de procesamiento de datos de transacción en comunicación con un sistema de procesamiento de datos comercial, un sistema de procesamiento de datos de banca emisora, y un sistema IPSP comercial, caracterizado porque el sistema de procesamiento de datos de procesamiento de transacción se arregla para conducir las etapas de proceso i de autenticación de pago de un método de conformidad con cualquiera de la reivindicación 21 a reivindicación 29.1
36. Un sistema de procesamiento de transacción para procesar solicitudes de autorización de pago ( para transacciones de pago que se conducen vía una red de comunicaciones de datos, las solicitudes de autorización de pago se conducen como un resultado de pedidos por titulares de cuentas financieras vía una pluralidad de diferentes sistemas comerciales en linea, en donde los titulares de cuentas financieras mantienen cuentas con una pluralidad de diferentes bancos emisores, y el sistema de procesamiento de autorización de pago comprende una interfaz arreglada para habilitar la comunicación sobre la red de comunicaciones de datos con sistemas de procesamiento de la pluralidad de I diferentes bancos emisores, caracterizado porque el sistema i de procesamiento de transacción se arregla para ejecutar un procedimiento de identificación de cuenta que comprende: identificar, vía las comunicaciones don la pluralidad de diferentes bancos emisores, un banco emisor asociado con un titular de cuentas financieras; sobre la base de la identificación deli banco emisor, recuperar los datos de transmisión de banco1 emisor vía la interfaz para habilitar la transmisión de datos de solicitud de identificación de cuenta, los datos de transmisión de banco emisor son dependientes del banco, emisor identificado e identificar un sistema de identificación de cuenta seleccionada asociado con el · banco ' emisor identificado; sobre la base de los datos de transmisión de banco emisor recuperados, transmitir una solicitud de identificación de cuenta vía la interfaz para uso' en la I autorización de al menos una transacción de pago, al menos í una transacción de pago se inicia como un resultado de que un 84 ¡ titular de cuentas financieras conduce al menos un pedido vía i al menos unos sistemas comerciales en línea; y { recibir una respuesta de identificación de^ cuenta vía la interfaz en respuesta a la solicitud de identificación de cuenta, la respuesta de identificación de 1 cuenta identifica una identidad de cuenta financiera capaz 'de ser usada en al menos unas transacciones de pago. 1
37. Un sistema de procesamiento de transacción para autorizar transacciones conducidas vía una red de comunicaciones de datos, el sistema de procesamiento de datos i de procesamiento de transacción responde a un pedido ,por un titular de cuenta financiera recibido vía un sistema de procesamiento de datos comercial, el sistema de procesamiento de transacción comprende medios de acceso de datos arreglados para acceder a los detalles de autenticación de banca en línea almacenados para un proceso de autenticación de banca en línea por lo cual un titular de cuentas financieras es capaz de acceder a una aplicación de banca en línea, la aplicación de banca en línea se relacionada con al menos unas cuentas financieras del titular de cuentas financieras,^ y una interfaz arreglada para habilitar la comunicación con un sistema de procesamiento de datos comercial, un sist ma de procesamiento de datos de banca emisora asociado con la aplicación de banca en línea, y un sistema IPSP comercial, caracterizado porque el sistema de procesamiento de i i i I transacción se arregla para realizar un procedimiento que I comprende : 1 i recibir una solicitud vía la interfaz relacionada con la autorización de una transacción de pago, la solicitud se inicia como un resultado de que un titular de ! cuentas i financieras conduce un pedido en un sistema de procesamiento de datos comercial; en respuesta a la recepción de la solicitud, conducir un proceso de autenticación de pago en el cual el i titular de cuentas financieras proporciona detalles de autenticación correspondientes a los detalles de autenticación de banca en linea almacenados; ' en respuesta a la verificación de los detalles de autenticación introducidos contra los detalles de autenticación de banca en linea almacenados, el sistema de procesamiento de transacción recibe, de la aplicación de banca en linea, un número de cuenta principal (PAN) para uso en el procesamiento de pago; 1 transmitir el número de cuenta principal , (PAN) recuperado vía la interfaz a un sistema Proveedor de Servicio de Pagos por Internet (sistema IPSP comercial) para uso en la autorización de la transacción de pago. i I I I I i 86 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; las solicitudes de autorización de pago se conducen como un resultado de pedidos por titulares de cuentas financieras vía una pluralidad de diferentes sistemas comerciales en linea, y el titular de cuentas financieras mantiene cuentas con una pluralidad de diferentes bancos emisores. El método comprende conducir un procedimiento de identificación de cuenta que comprende: identificar, de la pluralidad de diferentes bancos emisores, un banco emisor asociado con un titular de cuentas financieras; sobre la base de la identificación del , banco emisor, recuperar los datos de transmisión de banco emisor i para habilitar la transmisión de datos de solicitud de identificación de cuenta, los datos de transmisión de banco i emisor son dependientes del banco emisor identificado e i identificar un sistema de identificación de cuenta seleccionada asociado con el banco emisor identificado; 1 sobre la base de los datos de transmisión de banco emisor recuperados, transmitir una solicitud de identificación de cuenta para uso en la autorización de al menos una I transacción de pago, al menos una transacción de pago se inicia como un resultado de que un titular . de cuentas 87 financieras conduce al menos un pedido vía al menos un sistema comercial en linea; y recibir una respuesta de identificación de cuenta en respuesta a la solicitud de identificación de cuenta, la respuesta de identificación de cuenta identifica una identidad de cuenta financiera capaz de ser usada en al menos una transacción de pago. Por consiguiente, las modalidades de la invención proporcionan un medio para identificar un bando emisor de una pluralidad de bancos emisores como uno el cual será utilizado en una transacción dada y facilitar que un usuario especifique, en tiempo real con relación a la transacción dada, una cuenta de banco particular que será usada para deducir fondos por esta transacción.
MX2011007356A 2009-01-08 2010-01-08 Sistema de pago. MX2011007356A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0900223A GB2466810A (en) 2009-01-08 2009-01-08 Processing payment authorisation requests
US12/416,902 US8688574B2 (en) 2009-01-08 2009-04-01 Payment system
PCT/EP2010/050158 WO2010079216A1 (en) 2009-01-08 2010-01-08 Payment system

Publications (1)

Publication Number Publication Date
MX2011007356A true MX2011007356A (es) 2012-01-27

Family

ID=40379286

Family Applications (1)

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

Country Status (9)

Country Link
US (4) US8688574B2 (es)
EP (1) EP2386095A1 (es)
KR (1) KR20110134383A (es)
CN (2) CN102349082A (es)
AU (1) AU2010204261B2 (es)
CA (1) CA2748914C (es)
GB (1) GB2466810A (es)
MX (1) MX2011007356A (es)
WO (1) WO2010079216A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11816667B2 (en) 2016-06-30 2023-11-14 Ipco 2012 Limited Generation of web pages for verification of data

Families Citing this family (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20120323735A1 (en) * 2005-09-28 2012-12-20 Saf-T-Pay, Inc. Payment system and clearinghouse of internet transactions
GB2466810A (en) 2009-01-08 2010-07-14 Visa Europe Ltd Processing payment authorisation requests
WO2012006628A2 (en) 2010-07-09 2012-01-12 Visa International Service Association Gateway abstraction layer
CA2823685C (en) * 2010-08-12 2017-03-07 Mastercard International, Inc. Multi-commerce channel wallet for authenticated transactions
US9805348B2 (en) * 2010-09-22 2017-10-31 Mastercard International Incorporated Methods and systems for initiating a financial transaction by a cardholder device
US8924297B2 (en) * 2011-02-25 2014-12-30 Visa International Service Association Direct connection systems and methods
US20120310774A1 (en) * 2011-05-31 2012-12-06 Chassin Christophe Electronic payment system
US20120330788A1 (en) * 2011-06-27 2012-12-27 Robert Hanson Payment selection and authorization by a mobile device
CN107730256B (zh) * 2011-09-09 2022-01-04 成都天钥科技有限公司 多因子多信道id认证和交易控制及多选项支付***及方法
US20130104197A1 (en) 2011-10-23 2013-04-25 Gopal Nandakumar Authentication system
US8713656B2 (en) 2011-10-23 2014-04-29 Gopal Nandakumar Authentication method
US9792593B2 (en) 2011-11-23 2017-10-17 The Toronto-Dominion Bank System and method for processing an online transaction request
US9292846B2 (en) * 2011-11-28 2016-03-22 Mocapay, Inc. Mobile device authorization system for concurrent submission of multiple tender types
KR20130098007A (ko) * 2012-02-27 2013-09-04 전용덕 개인 익명화 코드를 이용한 인증 통합 관리/운용 시스템 및 그 방법과 준 공공적 통합인증센터
WO2013142917A1 (en) * 2012-03-30 2013-10-03 Ip Payovation Pty Ltd Payment apparatus and method
CN103426088A (zh) * 2012-05-18 2013-12-04 符吉红 信息流处理***
CN103426239B (zh) * 2012-05-25 2015-10-28 ***股份有限公司 信息存储装置的发行机构的确定方法及确定装置
KR20140001025A (ko) * 2012-06-27 2014-01-06 최한겸 외국인 관광객을 위한 신용 결제 방법
US20150356553A1 (en) * 2012-09-26 2015-12-10 Petr Fedorovich Kutis System for verifying the authenticity of a payment card holder
CN104756139A (zh) * 2012-10-05 2015-07-01 谷歌公司 用于管理远程交易的***、方法和计算机程序产品
US20140181007A1 (en) * 2012-12-21 2014-06-26 Onomatics Inc Trademark reservation system
US9947007B2 (en) 2013-01-27 2018-04-17 Barry Greenbaum Payment information technologies
GB2513127A (en) * 2013-04-15 2014-10-22 Visa Europe Ltd Method and System for Activating Credentials
GB2513125A (en) 2013-04-15 2014-10-22 Visa Europe Ltd Method and system for transmitting credentials
CN105359179B (zh) 2013-05-15 2019-12-10 维萨国际服务协会 移动令牌化枢纽
US9870556B2 (en) * 2013-05-22 2018-01-16 Google Llc Split tender in a prepaid architecture
US20140351035A1 (en) 2013-05-22 2014-11-27 Google Inc. Auto-redeemable basket level offers in a prepaid architecture
GB2518392A (en) * 2013-09-19 2015-03-25 Visa Europe Ltd Account association systems and methods
US20150199671A1 (en) * 2014-01-13 2015-07-16 Fidelity National E-Banking Services, Inc. Systems and methods for processing cardless transactions
SG2014008932A (en) * 2014-02-06 2015-09-29 Mastercard Asia Pacific Pte Ltd A method and a corresponding proxy server, system, computer-readable storage medium and computer program
WO2015118388A1 (en) * 2014-02-06 2015-08-13 Spiritus Payments Private Limited System and method for electronic payment transaction
GB2523101A (en) * 2014-02-12 2015-08-19 Ipl Information Proc Ltd Method and system for executing online transfer of assets
US9619792B1 (en) * 2014-03-25 2017-04-11 Square, Inc. Associating an account with a card based on a photo
US9978054B2 (en) * 2014-04-11 2018-05-22 Mastercard International Incorporated Acceptance quality improvement using localization data to adjust contactless payment
NZ629194A (en) * 2014-08-22 2016-02-26 Avali Payments Ltd A method and apparatus for facilitating payments
US20160224973A1 (en) * 2015-02-01 2016-08-04 Apple Inc. User interface for payments
US20160232516A1 (en) * 2015-02-06 2016-08-11 Google Inc. Predictive authorization of mobile payments
US10528945B1 (en) 2015-03-31 2020-01-07 Square, Inc. Open ticket payment handling with incremental authorization
US10043162B1 (en) * 2015-03-31 2018-08-07 Square, Inc. Open ticket payment handling with bill splitting
US11301219B2 (en) 2015-05-22 2022-04-12 Paypal, Inc. Hosted sensitive data form fields for compliance with security standards
US9449320B1 (en) 2015-06-08 2016-09-20 Vantiv, Llc Closed-loop testing of integrated circuit card payment terminals
US10535067B2 (en) * 2015-07-01 2020-01-14 Mastercard International Incorporated Electronic incremental payments
CN108475374B (zh) * 2015-08-17 2022-04-19 维尔雷恩斯控股有限公司 具有多种进行金融交易的模式的支付设备
US9569757B1 (en) 2015-09-30 2017-02-14 Square, Inc. Anticipatory creation of point-of-sale data structures
WO2017104288A1 (ja) * 2015-12-14 2017-06-22 株式会社エヌティーアイ 決済システム、ユーザ端末及びそれで実行される方法、決済装置及びそれで実行される方法、並びにプログラム
US20170169432A1 (en) * 2015-12-15 2017-06-15 Mastercard International Incorporated System and method of identifying baker's fraud in transactions
CN111565183B (zh) 2015-12-17 2022-05-13 创新先进技术有限公司 跨***的业务操作执行方法、业务平台以及目标***
ITUB20159308A1 (it) * 2015-12-22 2017-06-22 Vinati S R L Metodo per effettuare pagamenti online
US11295293B2 (en) * 2016-01-07 2022-04-05 Worldpay, Llc Point of interaction device emulation for payment transaction simulation
US11250432B2 (en) * 2016-04-13 2022-02-15 America Express Travel Related Services Company, Inc. Systems and methods for reducing fraud risk for a primary transaction account
US20170357957A1 (en) * 2016-06-10 2017-12-14 Razorpay, Inc. Facilitating authentication for online payment
US10289992B1 (en) * 2016-06-17 2019-05-14 Square, Inc. Kitchen display interfaces with in flight capabilities
US10311420B1 (en) 2016-06-17 2019-06-04 Square, Inc. Synchronizing open ticket functionality with kitchen display systems
US10360648B1 (en) 2016-06-22 2019-07-23 Square, Inc. Synchronizing KDS functionality with POS waitlist generation
US10580062B1 (en) 2016-06-28 2020-03-03 Square, Inc. Integrating predefined templates with open ticket functionality
GB2555073A (en) * 2016-06-30 2018-04-25 Vocalink Ltd Push payment scheme through a trusted third party
US20180114203A1 (en) * 2016-10-21 2018-04-26 Mastercard International Incorporated Systems and methods for regulating access to data stored in a data source
SG10201609649RA (en) * 2016-11-17 2018-06-28 Mastercard International Inc Method and system for facilitating a cashless transaction
CN106600249A (zh) * 2016-12-22 2017-04-26 世纪禾光科技发展(北京)有限公司 拒付率控制方法及装置
WO2019027447A1 (en) * 2017-08-01 2019-02-07 Aci Worldwide Corp. COMPUTERIZED SYSTEM AND METHOD FOR FINANCING SELLER FINANCES IN AN INTEGRATED CLOSED LOOP SYSTEM
CN107578244A (zh) * 2017-08-07 2018-01-12 阿里巴巴集团控股有限公司 一种支付方法、装置及其设备
US11379550B2 (en) * 2017-08-29 2022-07-05 Paypal, Inc. Seamless service on third-party sites
US10943311B1 (en) 2017-09-29 2021-03-09 Square, Inc. Order fulfillment and tracking systems and methods
US10467559B1 (en) 2017-09-29 2019-11-05 Square, Inc. Order fulfillment and tracking systems and methods
US20190171985A1 (en) * 2017-12-05 2019-06-06 Promontory Financial Group Llc Data assignment to identifier codes
US20190188614A1 (en) * 2017-12-14 2019-06-20 Promontory Financial Group Llc Deviation analytics in risk rating systems
CN108229911A (zh) * 2017-12-20 2018-06-29 中智关爱通(上海)科技股份有限公司 一种支付方法、***、服务器、终端及其存储介质
WO2019195143A1 (en) * 2018-04-05 2019-10-10 Visa International Service Association System, method, and apparatus for authenticating a user
US10929429B2 (en) * 2018-05-03 2021-02-23 Hewlett Packard Enterprise Development Lp Flexible subscriber data abstraction layer
JP2020016980A (ja) * 2018-07-24 2020-01-30 弘樹 松平 決済補助システム及び決済補助方法
WO2020102188A1 (en) * 2018-11-13 2020-05-22 Mastercard International Incorporated Systems and methods for facilitating network voice authentication
US11138680B1 (en) 2018-11-21 2021-10-05 Square, Inc. Updating menus based on predicted efficiencies
SE1830356A1 (en) * 2018-12-07 2020-06-08 Omnicorn Ab Purchase Management System And Method
US10915905B1 (en) 2018-12-13 2021-02-09 Square, Inc. Batch-processing transactions in response to an event
EP3671613A1 (en) 2018-12-20 2020-06-24 Vocalink Limited A method, apparatus and computer program product for exchanging messages across a networ
CN110245925A (zh) * 2019-05-20 2019-09-17 陈旭 电子支付方法、***、装置及计算机可读存储介质
US11270275B2 (en) * 2019-08-16 2022-03-08 Comenity Llc One card
CN110910134B (zh) * 2019-10-25 2021-08-27 网联清算有限公司 支付处理***和方法
CN110852747B (zh) * 2019-10-31 2022-03-18 支付宝(杭州)信息技术有限公司 订单对账***、方法及装置
CN111131263B (zh) * 2019-12-26 2022-02-01 支付宝(杭州)信息技术有限公司 数据查看方法以及装置
CN111210215B (zh) * 2020-01-13 2024-04-26 中国银行股份有限公司 一种银行支付路径选择的处理方法、装置及电子设备
CN111552982B (zh) * 2020-04-27 2023-03-10 支付宝(杭州)信息技术有限公司 保护隐私的账户关联关系识别方法及装置
US11783310B1 (en) * 2020-06-16 2023-10-10 Block, Inc. Point-of-sale authorization
CN111861457B (zh) * 2020-06-28 2023-02-21 ***股份有限公司 支付令牌申请方法、设备、***和服务器
EP3933736A1 (en) * 2020-06-30 2022-01-05 Mastercard International Incorporated Techniques for performing authentication in ecommerce transactions
TWI795690B (zh) * 2020-11-11 2023-03-11 財金資訊股份有限公司 整合金融支付平台之方法及其系統
CN112633895A (zh) * 2021-01-05 2021-04-09 交通银行股份有限公司 银行线上网点业务数字货币交易的风险控制方法及***
US20220230237A1 (en) * 2021-01-15 2022-07-21 Eric Solis Credential push to credit push network
JP2024520523A (ja) * 2021-05-26 2024-05-24 ビザ インターナショナル サービス アソシエーション 口座間取引ネットワークのためのシステム、方法、及びコンピュータプログラム製品
WO2024081809A1 (en) * 2022-10-12 2024-04-18 Khosla Ventures LLC Cryptographic systems and methods for providing services to authenticated users

Family Cites Families (115)

* 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
US5453601A (en) * 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US5708422A (en) 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
US6198450B1 (en) 1995-06-20 2001-03-06 Naoki Adachi Dielectric resonator antenna for a mobile communication
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
JP2000020424A (ja) * 1998-06-26 2000-01-21 Class Technology:Kk アプリケーション間通信システム、アプリケーション間通信方法、及びアプリケーション間通信方法を記録したコンピュータ読み取り可能な記録媒体
DE19837266A1 (de) 1998-08-17 2000-02-24 Philips Corp Intellectual Pty Dielektrische Resonatorantenne
EP0987642A3 (en) 1998-09-15 2004-03-10 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
US6185545B1 (en) 1998-11-17 2001-02-06 Prenet Corporation Electronic payment system utilizing intermediary account
EP1006469A1 (en) 1998-12-02 2000-06-07 Koninklijke KPN N.V. System for secure transactions
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
AU4817300A (en) 1999-05-03 2000-11-17 Chase Manhattan Bank, The 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
US20070055884A1 (en) * 1999-05-19 2007-03-08 Rhoads Geoffrey B User control and activation of watermark enabled objects
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
FR2797352B1 (fr) 1999-08-05 2007-04-20 Cit Alcatel Antenne a empilement de structures resonantes et dispositif de radiocommunication multifrequence incluant cette antenne
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
US6734886B1 (en) * 1999-12-21 2004-05-11 Personalpath Systems, Inc. Method of customizing a browsing experience on a world-wide-web site
JP3494109B2 (ja) 2000-03-13 2004-02-03 Tdk株式会社 Temモード誘電体共振器を用いたバンドパスフィルタ
JP2001203513A (ja) 2000-01-21 2001-07-27 Tdk Corp 高周波誘電体共振器
US6621381B1 (en) 2000-01-21 2003-09-16 Tdk Corporation TEM-mode dielectric resonator and bandpass filter using the resonator
JP2001216461A (ja) 2000-02-04 2001-08-10 Just Syst Corp オンライン商品購入システム及び方法、オンライン商品購入指示装置及び方法、オンライン商品購入代理装置及び方法、並びに記録媒体
DE10005953A1 (de) 2000-02-09 2001-08-16 Heinz Leiber Verfahren zur Herstellung eines elektromagnetischen Aktuators und elektromagnetischer Aktuator
AU2001241477A1 (en) * 2000-02-10 2001-08-20 Fernando Munoz Transportation system for on-line transactions
AUPQ556600A0 (en) 2000-02-14 2000-03-02 Ong, Yong Kin (Michael) Electronic funds transfers-zipfund
US7865414B2 (en) * 2000-03-01 2011-01-04 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
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
JP5025875B2 (ja) 2000-04-24 2012-09-12 ビザ・インターナショナル・サービス・アソシエーション オンラインの支払人認証サービスの方法
US7516100B1 (en) 2000-05-12 2009-04-07 The Western Union Company Method and system for transferring money in business-to-business internet transactions
AU6661401A (en) * 2000-05-25 2001-12-03 Echarge Corp Secure transaction protocol
AU2001280297A1 (en) 2000-06-29 2002-01-08 Jonathan Ferrier An e-commerce system
US7890433B2 (en) 2000-06-30 2011-02-15 Tara Chand Singhal Private and secure payment system
AU2001273334A1 (en) 2000-07-11 2002-01-21 Paypal, Inc System and method for third-party payment processing
US7359880B2 (en) * 2000-07-11 2008-04-15 Abel Luther C System and method for consumer control over card-based transactions
CA2349306C (en) 2000-07-19 2006-10-10 Avaya Technology Corp. Method of and apparatus for executing automated transactions
US7337217B2 (en) * 2000-07-21 2008-02-26 Samsung Electronics Co., Ltd. Architecture for home network on world wide web
AU2000277066A1 (en) 2000-09-21 2002-04-02 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
US20020103752A1 (en) * 2001-01-30 2002-08-01 Caesar Berger E-commerce payment solution
US7292999B2 (en) * 2001-03-15 2007-11-06 American Express Travel Related Services Company, Inc. Online card present transaction
WO2002086829A1 (en) * 2001-04-16 2002-10-31 Mobile Solutions And Payment Services Pte Ltd Method and system for performing a transaction utilising a thin payment network (mvent)
US20020178115A1 (en) 2001-05-28 2002-11-28 Dong-Seok Seo System and method for supplying credit card information
WO2003001866A1 (en) * 2001-06-27 2003-01-09 Snapcount Limited Transcation processing
US9031880B2 (en) * 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
KR100444217B1 (ko) 2001-09-12 2004-08-16 삼성전기주식회사 표면실장형 칩 안테나
US7715377B2 (en) * 2002-01-03 2010-05-11 Integrated Device Technology, Inc. Apparatus and method for matrix memory switching element
JP2005522782A (ja) 2002-04-08 2005-07-28 エクソンモービル リサーチ アンド エンジニアリング カンパニー 多様な支払い選好を用いて金銭取引を処理するためのシステムおよび方法
US7707120B2 (en) 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7225462B2 (en) * 2002-06-26 2007-05-29 Bellsouth Intellectual Property Corporation Systems and methods for managing web user information
ATE375670T1 (de) 2002-07-01 2007-10-15 Ericsson Telefon Ab L M Anordnung und verfahren zum schutz von endbenutzerdaten
US8930270B2 (en) 2002-07-30 2015-01-06 Aol Inc. Smart payment instrument selection
FR2844399A1 (fr) 2002-09-09 2004-03-12 Thomson Licensing Sa Antennes de type resonateur dielectrique
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
WO2005003907A2 (en) * 2003-06-26 2005-01-13 Ebay Inc. Method and apparatus to authenticate and authorize user access to a system
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
CN1635525A (zh) * 2003-12-31 2005-07-06 ***股份有限公司 一种安全的网上支付***及安全的网上支付认证方法
US7580857B2 (en) 2004-04-16 2009-08-25 First Data Corporation Methods and systems for online transaction processing
US20060004658A1 (en) * 2004-07-02 2006-01-05 Wunchun Chau Method of processing credit payments at delivery
US10497008B2 (en) * 2004-11-05 2019-12-03 Hugues Courchesne Method for web-based distribution of targeted advertising messages
CN100417066C (zh) * 2004-12-29 2008-09-03 国际商业机器公司 用于处理基于浏览器的应用中的安全问题的多域访问代理
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
US7290704B1 (en) * 2005-06-21 2007-11-06 Robert Ball Method and system relating to a multi-lateral trade engine for payment transactions
US20060293984A1 (en) * 2005-06-27 2006-12-28 Wealth Management Systems, Inc. Rollover solutions
US20070106946A1 (en) * 2005-11-07 2007-05-10 Philip Goetz Method and system for developing interactive Web applications in a unified framework
US20070204010A1 (en) * 2005-12-12 2007-08-30 Steven Goldberg Remote Module Syndication System and Method
US20070185822A1 (en) * 2005-12-28 2007-08-09 Santosh Kaveti System and method for online third-party payment processing
JP2007286697A (ja) * 2006-04-12 2007-11-01 Mastercard Internatl Japan Inc 支払い処理支援装置及び支払い処理支援方法
US8099329B2 (en) 2006-04-25 2012-01-17 Uc Group Limited Systems and methods for determining taxes owed for financial transactions conducted over a network
EP2365468A1 (en) * 2006-04-25 2011-09-14 UC Group Ltd. Systems and methods for conducting financial transactions over a network
US8402357B1 (en) * 2006-06-15 2013-03-19 Michael R. Norwood System and method for facilitating posting of public and private user comments at a web site
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
WO2008007939A1 (en) * 2006-07-11 2008-01-17 Liang Shing Ng Convenient online payment system
WO2008014321A2 (en) * 2006-07-26 2008-01-31 Joseph Sally System for managing multiple credit accounts
US20080091528A1 (en) * 2006-07-28 2008-04-17 Alastair Rampell Methods and systems for an alternative payment platform
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
DE112007002744T5 (de) 2006-11-16 2009-10-08 Net1 Ueps Technologies, Inc. Gesicherte finanzielle Transaktionen
WO2008127431A2 (en) 2006-11-21 2008-10-23 Verient, Inc. Systems and methods for identification and authentication of a user
WO2008089263A2 (en) 2007-01-16 2008-07-24 Autoscribe Corporation System and method for electronic payment processing
WO2008115620A2 (en) * 2007-01-29 2008-09-25 Google Inc. On-line payment transactions
WO2008098163A2 (en) 2007-02-09 2008-08-14 Hopton Robert M Method to facilitate confidential network sales
US7716281B2 (en) * 2007-02-12 2010-05-11 Oomble, Inc. Method and system for transferring content from the web to mobile devices
ZA200905538B (en) 2007-02-27 2010-10-27 Emigrant Bank A method and system of facilitating a purchase between a buyer and a seller
CA2682610A1 (en) 2007-04-03 2008-10-09 Cpni Inc. A system and method for merchant discovery and transfer of payment data
WO2008123762A1 (en) * 2007-04-10 2008-10-16 Epetrol Holding Sdn. Bhd. Method and apparatus for performing a transaction
US8156543B2 (en) * 2007-04-17 2012-04-10 Visa U.S.A. Method and system for authenticating a party to a transaction
US7809785B2 (en) * 2007-05-28 2010-10-05 Google Inc. System using router in a web browser for inter-domain communication
US8121942B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Systems and methods for secure and transparent cardless transactions
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
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
US8108770B2 (en) * 2007-08-27 2012-01-31 Yahoo! Inc. Secure inter-module communication mechanism
US20090057396A1 (en) * 2007-08-27 2009-03-05 Eric Barbour Method and system for multiple account, token-based single transactions
US20090063850A1 (en) * 2007-08-29 2009-03-05 Sharwan Kumar Joram Multiple factor user authentication system
US7594035B2 (en) * 2008-02-22 2009-09-22 Tactara, Llc Methods of providing published content
US20100106611A1 (en) 2008-10-24 2010-04-29 Uc Group Ltd. Financial transactions systems and methods
GB2466676A (en) 2009-01-06 2010-07-07 Visa Europe Ltd A method of processing payment authorisation requests
GB2466810A (en) 2009-01-08 2010-07-14 Visa Europe Ltd Processing payment authorisation requests
US8429048B2 (en) * 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
CA3007992A1 (en) * 2017-06-13 2018-12-13 Justina-Miruna Vintila System and method for location-based token transaction processing

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11816667B2 (en) 2016-06-30 2023-11-14 Ipco 2012 Limited Generation of web pages for verification of data

Also Published As

Publication number Publication date
CN110070348B (zh) 2024-03-01
AU2010204261A1 (en) 2011-07-28
CN110070348A (zh) 2019-07-30
US20100174620A1 (en) 2010-07-08
KR20110134383A (ko) 2011-12-14
US20230306394A1 (en) 2023-09-28
AU2010204261B2 (en) 2016-09-08
CA2748914A1 (en) 2010-07-15
WO2010079216A1 (en) 2010-07-15
US20120011065A1 (en) 2012-01-12
GB2466810A (en) 2010-07-14
EP2386095A1 (en) 2011-11-16
CA2748914C (en) 2017-06-27
US11669816B2 (en) 2023-06-06
US20200226564A1 (en) 2020-07-16
US8688574B2 (en) 2014-04-01
GB0900223D0 (en) 2009-02-11
CN102349082A (zh) 2012-02-08

Similar Documents

Publication Publication Date Title
US11669816B2 (en) Payment system
US8942997B2 (en) Payment system
US7835960B2 (en) System for facilitating a transaction
US20150254672A1 (en) Processing authorization requests
JP2017079081A (ja) 仲介人介在支払システムおよび方法
JP2017517061A (ja) 仮想カード値を用いる取引の実行
KR20090081785A (ko) 대리운전 대금 정산 방법 및 시스템과 이를 위한 기록매체
US20190114602A1 (en) Configuration Tool for Payment Processing
KR20090057193A (ko) 입금경로 별 상점 회계정보를 통한 대출금액 산출 서버
KR100854355B1 (ko) 종교단체용 모바일 계좌 운용방법 및 시스템과 이를 위한프로그램 기록매체
KR20090060225A (ko) 입금경로 별 상점 회계정보를 통한 대출금액 산출 방법
KR20090002209A (ko) 인센티브 제공방법 및 시스템과 이를 위한 기록매체
KR20090060224A (ko) 입금경로 별 상점 회계정보 관리 방법 및 이를 위한 기록매체