ES2952995T3 - Método para procesar una transacción de pago, estación de pago y programa correspondiente - Google Patents

Método para procesar una transacción de pago, estación de pago y programa correspondiente Download PDF

Info

Publication number
ES2952995T3
ES2952995T3 ES18150881T ES18150881T ES2952995T3 ES 2952995 T3 ES2952995 T3 ES 2952995T3 ES 18150881 T ES18150881 T ES 18150881T ES 18150881 T ES18150881 T ES 18150881T ES 2952995 T3 ES2952995 T3 ES 2952995T3
Authority
ES
Spain
Prior art keywords
payment
offer
content
transaction
station
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18150881T
Other languages
English (en)
Inventor
Pierre Quentin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding SAS
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 Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Application granted granted Critical
Publication of ES2952995T3 publication Critical patent/ES2952995T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0237—Discounts or incentives, e.g. coupons or rebates at kiosk
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/352—Contactless payments by cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0238—Discounts or incentives, e.g. coupons or rebates at point-of-sale [POS]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/206—Software aspects at ATMs
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/211—Software architecture within ATMs or in relation to the ATM network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Databases & Information Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Abstract

La invención se refiere a un método para procesar una transacción de pago, método implementado por un dispositivo electrónico autónomo para procesar una transacción de pago, denominado terminal de pago (BP), comprendiendo dicho terminal de pago (BP) un procesador de procesamiento (Prc) conectado a al menos un medio de restitución de oferta de venta (Scr), y conectado a al menos una interfaz de comunicación (CI) y a al menos un terminal de pago sin contacto (TPNfc). Tal método comprende: - una etapa de transmisión (10), mediante un navegador (Nav) instalado dentro de dicho terminal de pago (BP), de una solicitud de obtención de contenidos (RqOC) a un servidor de contenidos (SrvCnt); - una etapa de recepción (20), por dicho navegador (Nav), desde el servidor de contenidos (SrvCnt), de contenidos html (HCnt) que comprenden al menos una etiqueta de pago (HPEIt); - una etapa de procesamiento (30) de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr); - una etapa de preparación (40), en anticipación y por parte del terminal de pago sin contacto (TPNfc), de al menos una transacción de pago (PT#) basada en datos de atributos de dicha al menos una etiqueta de pago (HPEIt). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método para procesar una transacción de pago, estación de pago y programa correspondiente
1. CAMPO TÉCNICO
La presente técnica se refiere a la gestión de dispositivos para el suministro de bienes y servicios no supervisados. Dichos dispositivos también se denominan "desatendidos" en la literatura de referencia. Más en particular, la presente invención se refiere a un método de tratamiento de transacciones de pago por intermedio de dichos dispositivos. Más en particular aún, se presenta un método para procesar transacciones de pago de bienes o servicios, así como un dispositivo configurado para la puesta en práctica de dicho método.
2. TÉCNICA ANTERIOR
Se conocen dispositivos cuyo objetivo es permitir a un usuario realizar una compra de bienes o servicios de forma independiente, es decir, sin la supervisión de un comerciante. Dichos dispositivos también se denominan "desatendidos" (sin vigilancia). Por ejemplo, estaciones de servicio, terminales de emisión de entradas de cine. Estas estaciones de pago convencionales son de pequeño tamaño y permiten realizar pagos utilizando un terminal de pago que acepta varias formas de pago, a saber, pago con tarjeta de circuito integrado y pago con tarjeta magnética.
Más recientemente han aparecido grandes estaciones. Se trata por lo general de estaciones multimedia, formadas por pantallas de gran tamaño (por lo general de 46 pulgadas de diagonal), que también pueden ser sensibles al tacto. Aparte de que son relativamente caras, los problemas técnicos que presentan estas estaciones son numerosos. El primero de ellos es que estas estaciones multimedia son de tipo propietario. Esto significa que una estación multimedia comprende un conjunto de componentes (pantalla, unidad central, sensores de presencia, sistema operativo, aplicación de gestión de la estación) que se disponen de manera conjunta para formar la estación. Incluso más recientemente, también se han desarrollado estaciones multimedia que incorporan funcionalidades de pago. Estas estaciones multimedia comprenden globalmente los mismos componentes que una estación multimedia convencional, pero, además, incorporan un terminal de pago, por lo general sin contacto. El documento US 2004/205491 A1 describe, por ejemplo, una estación multimedia de este tipo.
En dicha estación multimedia, también denominad estación de pago con referencia a las estaciones más pequeñas presentadas con anterioridad, se utiliza por ejemplo un terminal de pago de tipo NFC (Near Field Channel, en inglés), por ejemplo, también denominado transmisión de datos en campos cercanos. En concreto, para realizar un pago con una estación de pago de este tipo, el usuario fija su medio de pago compatible con NFC en un lugar muy específico de la estación para realizar el pago de lo que se muestra en pantalla. Puede ser un pago por un bien o un servicio. Puede ser, por ejemplo, el pago de entradas para espectáculos o una donación a una asociación. En algunos casos, esto puede implicar el pago de un bien (que luego se entrega en una dirección acordada).
Este tipo de estación es complicada de construir y de poner en práctica. De hecho, por regla general, las ofertas de productos o servicios que se muestran en la estación de pago están preprogramadas. Lo que antecede significa que o bien las ofertas se integran directamente en una memoria masiva de la estación, o bien, se descargan desde un servidor dedicado por intermedio de una red de comunicación. Las ofertas se registran en el servidor dedicado que tiene, para una determinada estación, un determinado número de ofertas. A solicitud, el servidor transmite una o más ofertas a una aplicación propietaria que se ejecuta en la estación de pago. La aplicación dedicada tiene las especificidades de la estación (tamaño de pantalla, número de terminales de pago) y adapta el contenido de las ofertas a la estación de pago en cuestión.
Dicha construcción dificulta de manera significativa el desarrollo de dichas estaciones de pago, al menos por dos motivos. En primer lugar, es necesario poner en práctica una aplicación dedicada. Esta aplicación dedicada, instalada en la propia estación, debe estar específicamente construida para dicha estación, o al menos especialmente compilada (y/o parametrada) para esta estación: es la que conoce el tamaño de la pantalla, el número de terminales de pago presentes y su funcionamiento. Lo que antecede significa que, para un gran número de estaciones, es necesario que el operador (de estas estaciones) disponga de un software especializado para la operación de parques de máquinas, incluyendo la gestión de configuraciones específicas. Sin embargo, dichas soluciones son caras. En segundo lugar, el desarrollo de este tipo de aplicaciones también es costoso. Cuando aparecen nuevas funcionalidades en los componentes instalados en las estaciones, es necesario volver a desarrollar la aplicación en cuestión para que pueda tener en cuenta estas nuevas funcionalidades.
Por lo tanto, existe la necesidad de proporcionar una solución simple, eficaz y ampliamente utilizable para simplificar la puesta en práctica de estaciones de pago.
3. SUMARIO
La invención no plantea estos problemas de la técnica anterior. Más concretamente, la invención proporciona una solución más sencilla a los problemas previamente identificados. De hecho, la presente técnica hace posible ofrecer una solución de integración de terminales de pago en una estación de pago que es más simple, menos costosa y más eficiente que las soluciones existentes.
Más en particular, la presente técnica se refiere a un método para procesar una transacción de pago según la reivindicación 1.
Por lo tanto, el contenido está asociado con una baliza de pago html estandarizada que permite que el navegador se comunique con un terminal de pago e inicie una transacción de pago.
Según una característica particular, la solicitud de obtención de contenido comprende al menos un dato de identificación de la estación de pago.
De este modo, el servidor es capaz de identificar los contenidos que están destinados a esta estación de pago. Según una característica particular, la etapa de tratamiento del contenido html comprende una etapa de determinación, dentro de la vista a representar, un emplazamiento de un dato representativo de la baliza de pago, en función de una posición de una antena sin contacto de dicho al menos un terminal de pago dentro de dicha estación de pago.
De este modo, la baliza de pago es claramente identificable para el usuario, que sabe exactamente dónde debe colocar su medio de pago para realizar el pago. Esta es la ventaja de utilizar una baliza: el navegador se encarga de mostrar el contenido HTML y, por lo tanto, de la baliza: el navegador adapta el posicionamiento de la baliza a la configuración de la pantalla.
Según una característica particular, dicha baliza de pago comprende al menos un atributo que define la oferta. Según una forma de realización particular, dicho atributo de definición de la oferta es una dirección de localización de una oferta, con un servidor transaccional, comprendiendo dicha dirección de localización un parámetro de identificación de la oferta y al menos un identificador de un terminal de pago perteneciente a dicha estación de pago. Según una característica particular, el método comprende una etapa de anulación de dicha al menos una transacción de pago, poniéndose en práctica dicha etapa de anulación cuando una duración de visualización de la oferta es igual a un parámetro temporal determinado y cuando no se ha realizado ningún pago durante el período temporal que comienza al final de la preparación de la transacción y finaliza en el tiempo definido por dicho parámetro temporal. De este modo, de forma periódica, es posible reiterar transacciones que han sido abiertas. De manera ventajosa, el parámetro temporal corresponde al tiempo máximo de apertura de la transacción con el servidor transaccional. Según una forma de realización particular, el método comprende, antes de la etapa de recepción por el navegador, un contenido que comprende dicha al menos una baliza de pago, a nivel del servidor de contenido:
- una etapa de recepción de la solicitud del navegador;
- una etapa de identificación, por intermedio de esta solicitud, de dicha estación de pago, que proporciona un identificador de dicha estación de pago;
- una etapa de obtención, dentro de una base de datos, en función del identificador, de un contenido a transmitir a dicha estación, comprendiendo dicho contenido al menos una oferta que incluye parámetros de oferta;
- una etapa de obtención, para cada oferta identificada en dicho contenido, de un par de datos que comprenden un identificador de terminal de pago y datos cifrados de la oferta;
- creación, por parte del servidor de contenidos, de una dirección de localización de la oferta, hacia un servidor transaccional que comprende el identificador del terminal de pago y dichos datos cifrados de la oferta;
- creación, a partir de dicho contenido y de las direcciones de localización de la oferta, del contenido html que comprende una baliza de pago por oferta.
Según una forma de realización particular, el método comprende, antes de la etapa de recepción por el navegador, de un contenido que comprende dicha al menos una baliza de pago, a nivel del servidor de contenido:
- una etapa de recepción de la solicitud del navegador;
- una etapa de identificación, por intermedio de esta solicitud, de dicha estación de pago, que proporciona un identificador de dicha estación de pago;
- una etapa de obtención, dentro de una base de datos, en función del identificador de la estación de pago, del contenido a transmitir a dicha estación, comprendiendo dicho contenido al menos una oferta que incluye parámetros de oferta;
- una etapa opcional de obtención, para cada oferta identificada en dicho contenido, de un servidor transaccional, de un dato representativo de un “reto” asociado a la oferta;
- una etapa de creación, a partir de dicho contenido y de los datos de la oferta, de un contenido html que comprende una baliza de pago de la oferta, que incluye el reto opcional.
La invención también se refiere a un dispositivo electrónico autónomo de tratamiento de transacciones de pago, denominado estación de pago, según la reivindicación 9.
De conformidad con una puesta en práctica preferida, las diversas etapas de los métodos, según la invención, se ponen en práctica mediante uno o más software o programas informáticos, que comprenden instrucciones de software destinadas a ser ejecutadas por un procesador de datos de un módulo de retransmisión según la invención y que están diseñadas para controlar la realización de las diversas etapas de los métodos.
En consecuencia, la invención también se refiere a un programa, capaz de ser ejecutado por un ordenador o por un procesador de datos, comprendiendo este programa instrucciones para controlar la ejecución de las etapas de un método tal como se mencionó con anterioridad.
Este programa puede utilizar cualquier lenguaje de programación y estar en forma de código fuente, código objeto o código intermedio entre el código fuente y el código objeto, como en una forma parcialmente compilada, o en ninguna otra forma deseable.
La invención también se refiere a un medio de información legible por un procesador de datos y que comprende instrucciones de un programa tal como se mencionó con anterioridad.
El soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede incluir un medio de almacenamiento, tal como una memoria ROM, por ejemplo, un CD ROM o una memoria ROM de circuito microelectrónico, o incluso un medio de registro magnético, por ejemplo, un disquete (floppy disk) o un disco duro.
Por otro lado, el medio de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede transmitirse por intermedio de un cable eléctrico u óptico, por radio o por otros medios. En particular, el programa, según la invención, puede descargarse de una red de tipo Internet.
De manera alternativa, el soporte de información puede ser un circuito integrado en donde se incorpora el programa, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución del método en cuestión.
Según una forma de realización, la invención se pone en práctica por medio de componentes de software y/o hardware. Desde esta perspectiva, el término "módulo" puede corresponder, en este documento, tanto a un componente de software, como a un componente de hardware o a un conjunto de componentes de hardware y software.
Un componente de software corresponde a uno o más programas informáticos, uno o más subprogramas de un programa, o más por lo general, a cualquier elemento de un programa o software capaz de poner en práctica una función o un conjunto de funciones, tal como se describe a continuación para el módulo en cuestión. Dicho componente de software es ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, enrutador, etc.) y es probable que acceda a los recursos de hardware de esta entidad física (memorias, soporte de registro, bus de comunicación, tarjetas electrónicas de entradas/salidas, interfaces de usuario, etc.).
Del mismo modo, un componente de hardware corresponde a cualquier elemento de un conjunto material (o hardware) capaz de poner en práctica una función o un conjunto de funciones, según lo que se describe a continuación para el módulo en cuestión. Puede ser un componente de hardware que se pueda programar o que tenga un procesador integrado para ejecutar software, por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para ejecutar un microsoftware (firmware), etc.
Por supuesto, cada componente del sistema descrito con anterioridad pone en práctica sus propios módulos de software.
Las diversas formas de realización mencionadas con anterioridad se pueden combinar entre sí para la puesta en práctica de la invención.
4. DIBUJOS
Otras características y ventajas de la invención aparecerán más claramente con la lectura de la siguiente descripción de una forma de realización preferente, proporcionada a modo de ejemplo sencillo, ilustrativo y no limitativo, y de los dibujos adjuntos, entre los cuales:
- las Figuras 1A y 1B muestran una estación de pago objeto de esta invención;
- la Figura 2 presenta, con mayor detalle, los componentes de dicha estación de pago;
- la Figura 3 muestra, en general, la obtención de datos de transacciones por parte del navegador integrado en una estación de pago objeto del presente documento;
- la Figura 4 describe la puesta en práctica de una baliza de pago en una forma de realización específica;
- la Figura 5 describe la puesta en práctica de una baliza de pago en otra forma de realización.
5. DESCRIPCIÓN
5.1 Descripción general
Tal como se ha descrito con anterioridad, en general, la técnica propone la sustitución de la aplicación “propietaria” para poner en práctica la estación de pago. Esta sustitución se realiza en beneficio de un navegador (también denominado “Browser, en inglés”). Esta sustitución permite tener solamente un número muy limitado de tipos de aplicaciones de gestión de estaciones de pago. Esencialmente, suponiendo que una estación de pago pueda poner en práctica un sistema Windows™ o un sistema Linux™, solamente se necesitan dos versiones del navegador: una para el entorno Windows™ y otra para el entorno Linux™.
Otra ventaja es dejar que el servidor se encargue de mostrar las ofertas en la estación. En efecto, puesto que la aplicación de gestión “convencional” se sustituye por un navegador, este último simplemente muestra los datos que se le transmiten, según un formato que también se le transmite. De este modo, según la presenta invención, el navegador recibe, desde el servidor, un documento de tipo “html”, al que se le añaden uno o varios recopiladores de hojas de estilo y una o varias bibliotecas de código “javascript”. La adición de estos datos se puede realizar insertando enlaces a recursos o directamente insertando los datos en el documento de tipo "html".
Sin embargo, aunque dicha puesta en práctica es interesante desde un punto de vista técnico y económico, no resuelve todo el problema. Más allá del problema de la gestión de la plataforma, también está la gestión de los pagos realizados por intermedio de la estación. Se recuerda que la estación es capaz de realizar pagos, por intermedio de uno o más terminales de pago integrados directamente en la estación. El uso de una aplicación “propietaria” en un entorno “controlado” tiene la ventaja de una gestión igualmente controlada del terminal de pago. La sustitución de esta aplicación "propietaria" por un navegador plantea problemas a resolver, y en particular el del control de los terminales de pago y el del control de los pagos a realizar.
Para resolver este problema, se pone en práctica una nueva baliza, denominada baliza de pago, de conformidad con esta técnica. Esta baliza, conocida por el navegador, incluye datos relativos al pago a realizar por la estación de pago. El funcionamiento de esta baliza se detalla a continuación. Cuando el navegador de la estación recibe (procedente del servidor), el documento de tipo html, el navegador muestra este documento en la pantalla de la estación, adornado con los estilos de las hojas de estilo e incluyendo el código de tipo "javascript". Al menos una baliza de pago está presente dentro de este documento, una baliza de pago que el navegador interpreta para realizar las acciones requeridas por esta baliza, y esto en relación con el o los terminales de pago de la estación de pago.
Se describe, en relación a las Figuras 1A y 1B, una estación de pago objeto de la presente invención. Dicha estación se presenta bajo la forma de una carcasa, que comprende un medio de restitución de información, tal como una pantalla y/o un altavoz. El medio de restitución de información está conectado por intermedio de uno o más buses de datos a un procesador de tratamiento. Este procesador puede ser cualquier tipo de procesador destinado habitualmente a este tipo de tareas, tal como procesadores de tipo PC o procesadores destinados a terminales más compactos (tales como sistemas en circuito integrado, "SOC" en inglés por "System on Chip"). El procesador de tratamiento comprende un bus de acceso a una memoria de acceso aleatorio, un bus de acceso a una memoria masiva, un bus de acceso a una o más interfaces de comunicación de red (WiFi, Bluetooth, interfaz de red de tipo RJ45) y uno o más buses de acceso a interfaces de comunicación de tipo serie ("USB" por "Universal Serial Bus" en inglés). Además, el procesador comprende un bus de acceso a al menos un terminal de comunicación que se presenta bajo la forma de un terminal de pago del tipo sin contacto. Dicho terminal de pago sin contacto comprende un procesador de tratamiento seguro, una memoria segura, un bus de acceso a un procesador NFC, una antena NFC conectada al procesador NFC. El terminal de pago también puede incluir una o más interfaces de comunicación dedicadas. Dependiendo de las formas de realización, las interfaces de comunicación del terminal de pago pueden compartirse con las interfaces de comunicación del procesador de tratamiento. El procesador de tratamiento y los distintos módulos que componen la estación de pago están controlados por un sistema operativo. El sistema operativo es estándar y puede basarse en una versión derivada del sistema Linux™. Incluye módulos para la gestión de los distintos componentes de la estación de pago, a excepción del o de los terminales de pago. El sistema operativo, por su parte, opera un navegador adaptado a la puesta en práctica de la presente invención, y en particular adaptado a la gestión y explotación de balizas de pago. Un terminal de pago, por su parte, también está controlado por un sistema operativo, de tipo propietario (esto no cambia respecto a las estaciones de la técnica anterior).
Sin embargo, los datos transmitidos al terminal de pago y recibidos desde el terminal de pago son significativamente diferentes de los de la técnica anterior, tal como se explica a continuación.
Se presenta en relación con la Figura 2, la arquitectura de una estación de pago según esta técnica. Dicha estación de pago (BP) comprende una pantalla (Scr), preferiblemente una pantalla táctil. Una pantalla de este tipo tiene un tamaño suficiente para poder mostrar, de manera visible para los transeúntes, uno o varios mensajes publicitarios. De este modo, la pantalla suele tener un tamaño comprendido de entre 32 y 55 pulgadas en diagonal. Un mensaje publicitario típico mostrado por una pantalla de este tipo incluye, por ejemplo, un video y/o fotografías y/o texto.
Según el entorno de destino de la estación de pago (BM), esta último también puede incluir un módulo de restitución de sonido (MSon): el módulo de restitución de sonido está destinado a producir sonidos que pueden acompañar a los mensajes publicitarios emitidos, cuando dichos sonidos pueden ser percibido por los usuarios.
La pantalla (Scr) y el módulo de reproducción de sonido (si está presente) están conectados por uno o dos buses de transporte de datos a un procesador de tratamiento (Proc). Dicho procesador (Proc) incluye suficientes capacidades de tratamiento para realizar diversas tareas de tratamiento multimedia, tales como mostrar vídeo de alta calidad y/o mostrar imágenes de mayor resolución. El procesador (Proc) también puede recibir datos por intermedio del bus de transporte de datos que conecta el procesador (Proc) al módulo NFC (si este último no está gestionado directamente por los terminales de pago integrados) o módulos de comunicación inalámbrica (tales como el módulo WiFi o el módulo Bluetooth, BLE).
El procesador (Proc) también está, de manera opcional conectado, por intermedio de un bus de datos, a sensores (ultrasonidos US, infrarrojos IR o incluso una cámara CAM) para recibir las señales emitidas por estos sensores con el fin de detectar posiblemente la presencia de uno o más usuarios. Estas señales son transformadas por el procesador y suministradas al sistema operativo (SO). El procesador también incluye memoria de acceso aleatorio (RAM) y memoria de almacenamiento (MAS).
El sistema operativo es responsable de hacer funcionar el navegador y de gestionar los intercambios de datos entre los distintos componentes y el navegador. En otras formas de realización, la estación de pago puede adoptar la forma de un terminal del tipo ordenador, tableta electrónica o teléfono inteligente, que incorpore componentes idénticos o similares en sus funciones y que sea capaz de poner en práctica los métodos aquí descritos, en cuyo caso la expresión de estación de pago será sustituida por una expresión más apropiada.
Se describe, en relación con la Figura 3, el funcionamiento general de una estación de pago para realizar un pago. Inicialmente, la estación de pago debe recibir, desde el servidor, los datos a visualizar y la información relativa a los pagos. El método puesto en práctica en esta ocasión es el siguiente:
- una etapa de transmisión (10), al servidor de contenidos (SrvCnt), de una solicitud de obtención de contenido (RqOC), comprendiendo dicha solicitud de obtención de contenido al menos un dato de identificación (iBP) de la estación de pago
o esta solicitud se pone en práctica desde la estación de pago; es por tanto la estación la que solicita los datos a visualizar, y esto para permitir una correcta ejecución de un pago, tal como se explica a continuación
- una etapa de recepción (20), desde el servidor de contenidos (SrvCnt), de al menos un contenido html (HCnt) a visualizar, comprendiendo dicho contenido al menos una baliza de pago (HPElt);
- una etapa de tratamiento (30) de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr), que comprende en particular la visualización, por dicho navegador, de dicho contenido, siendo mostrados datos representativos de la baliza de pago en la proximidad de una antena NFC de un terminal de pago de la estación de pago.
De manera complementaria, el contenido del documento de tipo html también incluye un dato representativo de un tiempo de visualización del contenido. Transcurrido este tiempo de visualización, se vuelve a ejecutar el método anterior, para mostrar nuevos contenidos en pantalla. El objeto de esta última etapa es doble: por un lado, permite no mostrar de forma permanente un contenido "estático" que tendría como consecuencia, por un lado, reducir la vida útil del dispositivo de visualización y, por otro, tener un efecto relativamente engañoso (esencialmente debido al hecho de que una pantalla fija no atrae la vista y, por lo tanto, no mejora las ofertas de bienes y servicios que se muestran en la estación de pago).
En segundo lugar, posteriormente o al mismo tiempo con la visualización del contenido en pantalla, el terminal de pago prepara (40), por adelantado (por anticipación), la(s) transacción(es) a realizar. El número de transacciones preparadas depende, por un lado, del número de terminales de pago instalados en la estación y, por otro lado, del número de balizas presentes en el contenido. Por ejemplo, si existen cuatro terminales de pago y solamente tres balizas, solamente se preparan tres transacciones. Por el contrario, si se instalan tres terminales de pago en la estación de pago y están presentes cuatro balizas de pago, solamente se preparan tres transacciones. Preparar una transacción (con antelación, es decir, antes de que un usuario haya manifestado su intención de adquirir un bien o servicio) tiene dos finalidades: por un lado, no tener que detectar la presencia del usuario (para iniciar la transacción) y por otro lado permitir el pago inmediato (cuando el medio de pago sea utilizado por el usuario).
La preparación de una transacción se realiza esencialmente gracias a la(s) baliza(s) de pago contenidas en el documento html.
Una baliza de pago, según la presente invención, es esencialmente una instrucción, destinada al navegador, que permite a este último preparar la transacción y ésta, cualquiera que sea la naturaleza de la misma. Una baliza de pago es una especie de interfaz universal entre el servidor, que transmite el contenido y el terminal de pago. La baliza de pago se pone en práctica junto con el navegador. La baliza de pago por lo general toma la siguiente forma:
<compra> </compra>
La baliza de pago incluye una serie de atributos, entre ellos los habituales de identificación ("id", "name", "image") y estilos que permiten mostrar el contenido de la etiqueta cuando es necesario. La baliza de pago también incluye atributos específicos que ayudan a preparar la transacción de pago. Esencialmente, se utilizan dos métodos, exclusivos o complementarios, según la puesta en práctica, para preparar la transacción.
Los posibles atributos de la baliza son los siguientes:
- enlace: especifica una dirección de localización de datos de transacción; se trata de un atributo para la obtención datos de transacciones desde un emplazamiento diferente a la del contenido;
- cantidad: especifica la cantidad de la transacción;
- moneda: especifica la moneda de la transacción;
- comerciante: especifica los parámetros del comerciante;
o los parámetros del comerciante pueden (y lo son con mayor frecuencia) cifrarse: corresponde al terminal de pago descifrar esta información a partir de los datos de los que tiene conocimiento;
- reto: especifica un reto: el reto proviene, por ejemplo, de un servidor remoto, diferente del servidor de contenido, y permite que el terminal de pago realice una autenticación mutua, por ejemplo, antes del pago, al preparar la transacción.
Cuando se han visualizado los datos y los terminales de pago de la estación de pago han preparado las transacciones (con anticipación), los pagos pueden ser realizados por los usuarios colocando su medio de pago en los lugares indicados por las balizas de pago, de las cuales en al menos algunos datos se muestran en la pantalla (por ejemplo, el precio y/o un logotipo de pago sin contacto).
Pueden ocurrir dos eventos al final de la preparación de la transacción: o se realiza un pago, por parte de un usuario, por una de las ofertas mostradas, o no se realiza ningún pago (dentro de un período temporal determinado). En este caso, el método comprende una etapa de anulación de las transacciones de pago (PT#) realizadas por anticipado, realizándose la anulación cuando una duración de visualización de la oferta es igual a un parámetro temporal determinado y cuando no se ha realizado ningún pago durante el período temporal que comienza al final de la preparación de la transacción y termina en el tiempo definido por dicho parámetro temporal. Si se produce esta anulación, se vuelve a poner en práctica el método descrito con anterioridad (etapas 10 a 40), dando como resultado la visualización de (nuevas) ofertas y la apertura de nuevas transacciones de prepago. De manera inteligente, el parámetro temporal corresponde al tiempo máximo durante el cual una transacción abierta por anticipado está activa (y/o está en función) a nivel del servidor transaccional (y/o del servidor que procesará la transacción).
5.2 Puesta en práctica de una baliza de pago
Existen principalmente dos métodos para poner en práctica esta baliza de pago: uno utilizando el atributo de enlace y otro utilizando los atributos descriptivos. La distinción entre la puesta en práctica del primer método y el segundo método puede tener en cuenta los parámetros físicos de la estación de pago, pero también parámetros relacionados con la transacción en sí misma (importe, por ejemplo) o incluso parámetros específicos del comerciante (que gestiona un conjunto de estaciones de pago). Por lo tanto, la puesta en práctica de uno u otro método a menudo está predefinida. La puesta en práctica de la baliza de pago permite que el terminal de pago cree, por adelantado, la(s) transacción(es) asociadas a las ofertas presentes en el contenido. Lo que antecede es inteligente, porque la creación de la transacción por anticipado permite procesar esta última de manera más rápida que lo que se propone en las soluciones de la técnica anterior.
5.2.1 Primer método de puesta en práctica
Un primer método, que no es objeto de la presente invención, consiste en proporcionar al terminal de pago los datos de preparación de la transacción por intermedio de una URL. En este caso, la baliza utiliza el atributo “link” que, si se valoriza, incluye un enlace (una URL) a un recurso seguro que contiene los datos de la transacción a preparar. Esta URL puede ser una dirección para el servidor de contenido (el que entregó el contenido html para mostrar) o para un servidor de terceros (un servidor de un comerciante que vende el producto).
Esta URL permite, por ejemplo, que el navegador (dependiendo del material criptográfico que incorpore) de la estación de pago tenga conocimiento de los datos de la transacción y configure el terminal de pago para preparar esta transacción. Sin embargo, de manera más eficaz, esta URL permite directamente al terminal de pago seleccionado tener conocimiento directamente de los datos de la transacción y configurar en consecuencia y autentificar con un servidor de transacciones.
De este modo, para poner en práctica dicho método, a partir de la baliza de enlace <link>, según al menos un ejemplo, descrito en relación con la Figura 4, cuando el navegador (Nav) transmite una solicitud para la obtención de contenido al servidor de contenidos (SrvCnt), el servidor de contenido (SrvCnt) pone en práctica el siguiente proceso:
- la recepción (S01) de la solicitud (RqOC) desde el navegador (Nav);
- la identificación (S02), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- la obtención (S03), dentro de una base de datos (BD), en función del identificador (iBP) de la estación de pago (BP), de un contenido (Cnt) para ser transmitido a dicha estación de pago (BP), comprendiendo dicho contenido al menos una oferta (Oi) que comprende parámetros de oferta (una moneda, un importe, una fecha, una duración y parámetros del comerciante, número de cuenta, banco, por ejemplo);
- la obtención (S04), para cada oferta (Oi) identificada en dicho contenido, de un par de datos que comprenden un identificador del terminal de pago (vxi) y un dato cifrado de la oferta (DCOi), comprendiendo esta obtención: - transmisión de dicha oferta (Oi) hacia un servidor transaccional (CTO);
- la determinación, entre los terminales de pago (vx1,...vx6) de la estación de pago, de un identificador del terminal de pago (vxi) encargado de una transacción asociada a esta oferta (Oi);
- la creación, a partir de los parámetros de la oferta y/u otros parámetros, de un dato cifrado de la oferta (DCOi);
- estos datos se cifran utilizando la clave pública del terminal de pago a cargo (vxi);
- cuando el terminal de pago tiene conocimiento de estos datos, puede autenticarlos como generados por el servidor de transacciones (véase a continuación).
- el atributo "reto" ("challenge") también puede ser generado por el servidor de transacciones en esta ocasión (para permitir que el terminal de pago asuma el reto generado por el servidor de transacciones antes de preparar la transacción);
- la transmisión, por parte del servidor transaccional (CTO), al servidor de contenidos (SrvCnt), del par formado por el identificador del terminal de pago (vxi) y dichos datos cifrados de la oferta (DCOi);
- la creación (S05), por parte del servidor de contenidos (SrvCnt), de una dirección de localización de la oferta (@LROi), hacia el servidor transaccional (CTO) que comprende el identificador del terminal de pago (vxi) y dichos datos cifrados de la oferta (CODi);
- la creación (S06), a partir de dicho contenido (Cnt) y direcciones de localización de oferta (@LROi), del contenido html (HCnt) que comprende una baliza de pago (HPElt) por oferta (Oi).
Este método tiene la ventaja de no requerir el suministro de datos "secretos" al navegador. De hecho, con este método, el navegador no sabe cuáles son los datos de la oferta. Estos datos son encriptados y transmitidos directamente por el navegador (y la API correspondiente) al terminal de pago cuyo identificador está presente en la URL. Por lo tanto, incluso si el navegador está comprometido (es decir, está sujeto a vigilancia para alterar su funcionamiento o alterar las transacciones de pago), no es posible modificar los datos de la oferta, que están encriptados y descifrables solamente por el terminal de pago designado para esta oferta (vxi). Sin embargo, este método tiene la desventaja, para el navegador, de tener que obtener los datos de la oferta del terminal de pago y, por lo tanto, requiere intercambios adicionales entre el terminal de pago y el navegador (intercambios que, por supuesto, están protegidos). Por lo tanto, este método es más efectivo en términos de seguridad, pero más restrictivo en términos de puesta en práctica.
5.2.2 Segundo método de puesta en práctica
Un segundo método de puesta en práctica de la baliza de pago, que es objeto de la presente invención, consiste en suministrar al terminal de pago datos de preparación de la transacción por intermedio de los atributos de la baliza (importe, moneda, parámetros del comerciante, fecha, reto). En este caso, el atributo de enlace no se utiliza necesariamente. Además, la obtención de los datos del servidor de contenidos (SrvCnt) es diferente al método anterior.
Para poner en práctica dicho método, a partir de las balizas de la oferta, según la presente invención, en al menos una forma de realización, descrita en relación con la Figura 5, cuando el navegador (Nav) transmite una solicitud de contenido al servidor de contenido (SrvCnt), siendo el método siguiente puesto en práctica por el servidor de contenido (SrvCnt):
- la recepción (S11) de la solicitud (RqOC) desde el navegador (Nav);
- la identificación (S12), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- la obtención (S13), dentro de una base de datos (BD), en función del identificador (iBP) de la estación de pago (BP), de un contenido (Cnt) para ser transmitido a dicha estación de pago (BP), comprendiendo dicho contenido al menos una oferta (Oi) que incluye parámetros de oferta (una moneda, un importe, una fecha, una duración y parámetros del comerciante, número de cuenta, banco, por ejemplo);
- la obtención (S14), de manera opcional, para cada oferta (Oi) identificada en dicho contenido, desde un servidor transaccional (CTO), de un "reto" asociado a la oferta (Oi) que comprende:
- la transmisión de dicha oferta (Oi) al servidor transaccional (CTO);
- la creación, a partir de los parámetros de la oferta y/u otros parámetros, de un dato de reto encriptado (DCChi);
- la transmisión, por parte del servidor transaccional (CTO), de dichos datos de reto cifrados (DCCh);
- la creación (S15), a partir de dicho contenido (Cnt) y de datos de oferta (Oi), de contenido html (HCnt) que comprende una baliza de pago (HPElt) por la oferta (Oi), que incluye el reto opcional (DCChi).
Esta forma de realización tiene la ventaja de permitir que el navegador integre directamente, dentro de la vista, los datos relativos a las ofertas, sin necesidad de decodificación alguna. Esta puesta en práctica es menos segura que la primera, pero también es más flexible. De hecho, el navegador toma nota directamente de los datos de la oferta, sin tener que llamar al terminal de pago y, por lo tanto, puede preparar la vista con mayor rapidez. El terminal de pago también recibe, desde el navegador, la oferta que le está destinada. Sobre la base de los datos recibidos, transmite una solicitud al servidor de transacciones y se realizan una serie de intercambios con el fin de permitir la autenticación del terminal, del servidor de transacciones, y de la oferta. El método puesto en práctica comprende las siguientes etapas:
- una etapa de recepción, por el terminal de pago, de los parámetros de la oferta; que son transmitidos por el navegador por intermedio de una API;
- una etapa de obtención de un dato representativo del servidor transaccional; que puede almacenarse en una memoria protegida del terminal de pago o ser proporcionada por el navegador;
- una etapa de creación, a partir de los parámetros de la oferta y una clave privada del terminal de pago, datos encriptados representativos de la oferta: el terminal de pago encripta los datos con su clave privada y posiblemente con la clave pública del servidor transaccional; por lo tanto, solamente el servidor transaccional, que tiene tanto la clave pública del terminal como su clave privada, puede descifrar los datos transmitidos por el terminal de pago;
- una etapa de transmisión de una solicitud de tratamiento a dicho servidor transaccional, comprendiendo dicha solicitud de tratamiento el dato cifrado representativo de la oferta y un identificador del terminal; y - cuando el servidor transaccional acepta los datos transmitidos por el terminal de pago, una etapa de recepción, del servidor transaccional, de un dato representativo de una aceptación del tratamiento de una transacción, para dicha oferta, por el terminal de pago.
Por lo tanto, solamente un terminal de pago auténtico y un servidor transaccional pueden preparar una transacción que también sea auténtica. Conviene señalar que el uso de la baliza de pago permite, de manera ventajosa, "pasar" datos al terminal de pago de forma transparente para el servidor de contenidos. Lo que antecede permite tener una gestión mucho más sencilla del contenido a transmitir a las estaciones de pago: ya no es necesario tener contenido "propietario" y se puede utilizar uno de los contenidos estandarizados, sin que esto tenga ningún impacto en la seguridad de todas las transacciones realizadas por las estaciones de pago.
5.3 Puesta en práctica de un pago
El primer método de preparación de transacciones comprende, tal como se describió con anterioridad, el uso de una dirección en la baliza de "link". Esta forma de realización se pone en práctica más bien cuando el terminal de pago tiene sus propios recursos de comunicación hacia los servidores (pago y/o comerciante), tal como, por ejemplo, su propia interfaz de red, pero esto no es de ninguna manera obligatorio. En esta forma de realización, el terminal de pago recupera los datos de la transacción desde una URL de la baliza, siendo transmitida esta URL (segura, del tipo 'https://') por el navegador. El terminal de pago envía una solicitud al servidor, que lo identifica (por ejemplo, gracias al agente de usuario u otro parámetro agregado por el terminal a la URL) y verifica (o incluso proporciona) los datos de la transacción (importe, moneda, parámetros del comerciante, fecha, reto “challenge”).
Utilizando esta información, el terminal prepara la transacción, es decir, inicia la transacción y se pone a la espera del pago. Dicho de otro modo, el terminal actúa como si el comerciante hubiera solicitado el pago a un cliente. La diferencia es que a priori ni el comerciante ni el terminal tienen datos sobre la presencia o ausencia de un cliente potencial. Por lo tanto, la transacción permanece "abierta" durante un tiempo predeterminado. Tal como se ha descrito, si un cliente realiza un pago, al presentar un medio de pago frente a la antena sin contacto del terminal de pago, la transacción es validada por el terminal de pago de la estación. La ventaja de esta forma de hacer las cosas es que la ejecución de la transacción es rápida, que no existe la necesidad de detectar la presencia del usuario (del cliente) ya que es él quien se manifiesta al presentar sus medios de pago sin contacto ante el terminal. Esto resuelve, gracias a esta baliza y a esta forma de iniciar la transacción, a uno de los problemas expuestos con anterioridad con las estaciones de pago de la técnica anterior, a saber, la necesidad de detectar la presencia del usuario con sensores de presencia.
En el segundo método de preparación de transacciones se incluye la configuración, por parte del navegador, del terminal de pago para que prepare la transacción. Esta forma de realización se pone en práctica más bien cuando el terminal de pago no dispone de recursos de comunicación propios y el sistema operativo de la estación actúa como puerta de enlace a los servidores (pago y/o comerciante), pero no es obligatorio. En esta forma de realización, el navegador recupera los datos de la baliza de pago (importe, moneda, parámetros del comerciante, fecha, "reto") y transmite esta información al terminal de pago por intermedio de una API del terminal de pago, API que permite que el sistema operativo intercambie la información con el terminal de pago. Por lo demás, el proceso de inicialización de la transacción es el mismo que en el anterior y las ventajas obtenidas son idénticas.
5.4 Desarrollo de una transacción
Al ser la transacción preparada (con anticipación), la finalización de esta última es simple. Para ello, el usuario simplemente debe colocar su método de pago sin contacto (tarjeta sin contacto, teléfono) en el lugar indicado para que el terminal de pago pueda realizar la lectura de la información contenida en el método de pago y finalizar la transacción. A este respecto, justo después de inicializar la transacción, el terminal de pago envía una solicitud para la obtención los datos del pago. La transmisión de esta solicitud se realiza de forma cíclica, mientras dure la visualización, en la pantalla de la oferta de venta (del producto o servicio). Cuando el usuario coloca su medio de pago en el lugar indicado, el terminal de pago realiza la lectura inmediata de los datos de pago. El terminal de pago finaliza la transacción e informa al navegador de la finalización de la transacción por intermedio de la interfaz API del sistema operativo. Por tanto, el navegador carga, en lugar del contenido mostrado con anterioridad, un contenido de confirmación de compra.

Claims (10)

REIVINDICACIONES
1. Método para procesar una transacción de pago, método puesto en práctica por un dispositivo electrónico autónomo de tratamiento de transacciones de pago, denominado estación de pago (BP), comprendiendo dicha estación de pago (BP) un procesador de tratamiento (Prc) conectado a al menos un medio de restitución de oferta de venta (Scr), y conectado a al menos una interfaz de comunicación (CI) y a al menos un terminal de pago sin contacto (TPNfc), comprendiendo dicho método:
- una etapa de transmisión (10), por un navegador (Nav) instalado dentro de dicha estación de pago (BP), de una solicitud de obtención de contenido (RqOC) hacia un servidor de contenido (SrvCnt);
- una etapa de recepción (20), por parte de dicho navegador (Nav), procedente del servidor de contenidos (SrvCnt), de un contenido html (HCnt) representativo de al menos una oferta de venta, comprendiendo dicho contenido html (HCnt) una baliza de pago (HPElt) por oferta de venta incluida en dicho contenido html (HCnt);
- una etapa de tratamiento (30) de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr);
estando dicho método caracterizado porque comprende, además, una etapa de inicialización (40), antes de cualquier interacción de un usuario con dicha estación de pago con vistas a responder a una de dicha al menos una oferta de venta, de al menos una transacción de pago (PT #), estando cada una de dicha al menos una transacción de pago asociada a una de dicha al menos una oferta de venta incluida en dicho contenido html (HCnt), siendo el número de transacciones de pago inicializadas función del número de terminales de pago instalados en dicha estación de pago (BP) y del número de balizas de pago (HPElt) presentes en dicho contenido html (HCnt), comprendiendo dicha etapa de inicialización, para cada una de dicha al menos una transacción de pago, la configuración de uno diferente de dichos terminales de pago para la puesta en práctica de dicha transacción de pago, en función de datos de atributos de la baliza de pago (HPElt) de la oferta de venta asociada a dicha transacción de pago, comprendiendo la configuración de un terminal de pago:
- la obtención, a partir de dichos datos de atributo de la baliza de pago de la oferta de venta asociada con dicha transacción de pago, de parámetros de oferta que comprenden una fecha, un importe, una moneda, una duración y parámetros bancarios de un comerciante;
- la apertura de una transacción asociada con dichos parámetros de oferta utilizando dicho terminal de pago;
- el posicionamiento de dicho terminal de pago en un estado de espera de un pago relativo a dicha transacción abierta, manteniéndose dicho estado de espera únicamente durante un período predeterminado de visualización de la oferta de venta en dicho al menos un medio de restitución, cancelándose dicha transacción abierta si no se realizada ningún pago durante dicho período predeterminado.
2. Método según la reivindicación 1, caracterizado porque la solicitud de obtención de contenido (RqOC) comprende al menos un dato de identificación de la estación de pago.
3. Método según la reivindicación 1, caracterizado porque la etapa de tratamiento (30) del contenido html (HCnt) comprende una etapa de determinación, dentro de la vista a restituir, de un emplazamiento de un dato representativo de la baliza de pago, en función de una posición de una antena sin contacto de dicho al menos un terminal de pago dentro de dicha estación de pago.
4. Método según la reivindicación 1, caracterizado porque dicha baliza de pago comprende al menos un atributo que define la oferta.
5. Método según la reivindicación 4, caracterizado porque dicho atributo para definir la oferta es una dirección de localización (@LR) de una oferta, con un servidor transaccional, comprendiendo dicha dirección de localización un parámetro de identificación de la oferta y al menos un identificador de un terminal de pago perteneciente a dicha estación de pago.
6. Método según la reivindicación 1, caracterizado porque comprende una etapa de anulación de dicha al menos una transacción de pago (PT#), poniéndose en práctica dicha etapa de anulación cuando una duración de visualización de la oferta es igual a un parámetro temporal determinado y cuando no se haya efectuado ningún pago durante el período temporal que comienza al final de la inicialización de la transacción y finaliza en el tiempo definido por dicho parámetro temporal.
7. Método según la reivindicación 1, caracterizado porque comprende, previo a la etapa de recepción (20), por parte del navegador (Nav), del contenido que incluye dicha al menos una baliza de pago, a nivel del servidor de contenidos (SrvCnt):
- una etapa de recepción (S01) de la solicitud (RqOC) desde el navegador (Nav);
- una etapa de identificación (S02), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- una etapa de obtención (S03), dentro de una base de datos (DB), en función del identificador (iBP), de un contenido (Cnt) para ser transmitido a dicha estación de pago (BP), comprendiendo dicho contenido al menos una oferta (Oi) que incluye parámetros de oferta;
- una etapa de obtención (S04), para cada oferta (Oi) identificada en dicho contenido, de un par de datos que comprenden un identificador del terminal de pago (vxi) y datos cifrados de la oferta (DCOi);
- creación (S05), por parte del servidor de contenidos (SrvCnt), de una dirección de localización de la oferta (@LROi), hacia un servidor transaccional (CTO) que comprende el identificador del terminal de pago (vxi) y dichos datos encriptados de la oferta (CODi);
- creación (S06), a partir de dicho contenido (Cnt) y de las direcciones de localización de oferta (@LROi), del contenido html (HCnt) que comprende una baliza de pago (HPElt) por oferta (Oi).
8. Método según la reivindicación 1, caracterizado porque comprende, previo a la etapa de recepción (20) por parte del navegador (Nav), del contenido que comprende dicha al menos una baliza de pago, a nivel del servidor de contenidos (SrvCnt):
- una etapa de recepción (S11) de la solicitud (RqOC) desde el navegador (Nav);
- una etapa de identificación (S12), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- una etapa de obtención (S13), dentro de una base de datos (DB), en función del identificador (iBP) de la estación de pago (BP), de un contenido (Cnt) a transmitir a dicha estación de pago (BP), comprendiendo dicho contenido al menos una oferta (Oi) que incluye parámetros de oferta;
- una etapa opcional de obtención (S14), para cada oferta (Oi) identificada en dicho contenido, de un servidor transaccional (CTO), de un dato representativo de un "reto" (Chal) asociado a la oferta (Oi);
- una etapa de creación (S15), a partir de dicho contenido (Cnt) y de los datos de la oferta (Oi), de contenido html (HCnt) que comprende una baliza de pago (HPElt) por la oferta (Oi), que incluye el reto opcional (DCChi).
9. Dispositivo electrónico autónomo de tratamiento de transacciones de pago, denominado estación de pago (BP), comprendiendo dicha estación de pago (BP) un procesador de tratamiento (Prc) conectado a al menos un medio de restitución de oferta de venta (Scr), y conectado a al menos una interfaz de comunicación (CI) y a al menos un terminal de pago sin contacto (TPNfc), comprendiendo dicho dispositivo:
- medios de transmisión de una solicitud de obtención de contenido (RqOC) hacia un servidor de contenido (SrvCnt), puesto en práctica por un navegador (Nav) instalado dentro de dicha estación de pago (BP);
- medios de recepción, destinados al navegador (Nav), con origen en el servidor de contenido (SrvCnt), de un contenido html (HCnt) representativo de al menos una oferta de venta, comprendiendo dicho contenido html (HCnt) una baliza de pago (HPElt) por oferta de venta incluidas en dicho contenido html (HCnt);
- medios para procesar dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr);
estando dicho dispositivo caracterizado porque comprende, además, medios de inicialización, antes de cualquier interacción de un usuario con dicha estación de pago con vistas a responder a una de dicha al menos una oferta de venta, de al menos una transacción de pago (PT#), estando asociada cada una de dichas al menos una transacción de pago a una de dicha al menos una oferta de venta incluida en dicho contenido html (HCnt), siendo el número de transacciones de pago inicializadas función del número de terminales de pago instalados en dicha estación de pago (BP) y del número de balizas de pago (HPElt) presentes en dicho contenido html (HCnt), comprendiendo dichos medios de inicialización, para cada una de dicha al menos una transacción de pago, medios para configurar uno diferente de dichos terminales de pago para poner en práctica dicha transacción de pago, en función de datos de atributo de la baliza de pago (HPElt) de la oferta de venta asociada a dicha transacción de pago, incluyendo dichos medios de configuración:
medios para la obtención, a partir de dichos datos de atributo de la baliza de pago de la oferta de venta asociada con dicha transacción de pago, de parámetros de oferta que comprenden una fecha, una cantidad, una moneda, una duración y parámetros bancarios de un comerciante;
medios para abrir una transacción asociada con dichos parámetros de oferta por medio de dicho terminal de pago; - medios para el posicionamiento de dicho terminal de pago en un estado de espera de un pago relativo a dicha transacción abierta, manteniéndose dicho estado de espera solamente durante un período predeterminado de visualización de la oferta de venta en dicho al menos un medio de restitución, cancelándose dicha transacción abierta si no se realiza ningún pago durante dicho período predeterminado.
10. Producto de programa informático descargable desde una red de comunicación y/o almacenado en un medio legible por ordenador y/o ejecutable por un microprocesador, caracterizado porque comprende instrucciones de código de programa para la ejecución de un método de tratamiento según las reivindicaciones 1 a 8, cuando es ejecutado por un procesador.
ES18150881T 2017-01-17 2018-01-09 Método para procesar una transacción de pago, estación de pago y programa correspondiente Active ES2952995T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1750355A FR3061975B1 (fr) 2017-01-17 2017-01-17 Procede de traitement d’une transaction de paiement, borne de paiement et programme correspondant.

Publications (1)

Publication Number Publication Date
ES2952995T3 true ES2952995T3 (es) 2023-11-07

Family

ID=58547661

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18150881T Active ES2952995T3 (es) 2017-01-17 2018-01-09 Método para procesar una transacción de pago, estación de pago y programa correspondiente

Country Status (5)

Country Link
US (1) US11037186B2 (es)
EP (1) EP3349161B1 (es)
CA (1) CA2992190A1 (es)
ES (1) ES2952995T3 (es)
FR (1) FR3061975B1 (es)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7362265B2 (ja) * 2019-02-28 2023-10-17 キヤノン株式会社 情報処理装置、情報処理方法及びプログラム

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040205491A1 (en) * 2001-05-30 2004-10-14 Aravinda Korala Software and method for self-service applications
US11062412B2 (en) * 2004-05-19 2021-07-13 Touchpay Holdings, Llc Machines and process for managing a service account
US8626661B2 (en) * 2006-10-10 2014-01-07 Global Standard Financial, Inc. Electronic lockbox using digitally originated checks
US7567920B2 (en) * 2007-11-01 2009-07-28 Visa U.S.A. Inc. On-line authorization in access environment
US9098851B2 (en) * 2008-02-14 2015-08-04 Mastercard International Incorporated Method and apparatus for simplifying the handling of complex payment transactions
US20110208550A1 (en) * 2008-10-07 2011-08-25 Codapay Reverse payment transaction system and method
WO2010048375A1 (en) * 2008-10-22 2010-04-29 Newzoom, Inc. Vending store inventory management and reporting system
EP2182489A1 (en) * 2008-10-31 2010-05-05 Accenture Global Services GmbH System for controlling user access to a service
US20120036073A1 (en) * 2010-08-03 2012-02-09 Gourab Basu Intelligent estimates in authorization
US9292870B2 (en) * 2010-12-13 2016-03-22 Qualcomm Incorporated System and method for point of service payment acceptance via wireless communication
US20130006416A1 (en) * 2011-05-19 2013-01-03 Crane Merchandising Systems, Inc. Customer usage statistics gathering within vending machines
US20130054412A1 (en) * 2011-08-22 2013-02-28 American Express Travel Related Services Company, Inc. Methods and systems for contactless payments for online ecommerce checkout
US11507950B2 (en) * 2012-07-31 2022-11-22 Worldpay, Llc Systems and methods for secure normative intermediation of payments processing peripherals
EP2909805A4 (en) * 2012-10-22 2016-06-08 Jean-Louis Fiorucci APPARATUS AND METHODS FOR PROVIDING URBAN SERVICES
US9038894B2 (en) * 2012-11-20 2015-05-26 Cellco Partnership Payment or other transaction through mobile device using NFC to access a contactless transaction card
US9972046B2 (en) * 2013-09-26 2018-05-15 Amazon Technologies, Inc. Mobile transactions with a kiosk management system
FR3021799B1 (fr) * 2014-05-28 2017-10-13 Compagnie Ind Et Financiere Dingenierie Ingenico Methode d'identification, dispositif et programme correspondant
US9424568B2 (en) * 2014-05-29 2016-08-23 Apple Inc. Financial-transaction notifications
US10096183B2 (en) * 2014-06-02 2018-10-09 Best Lockers, Llc Mobile kiosk for intelligent securable devices system
CA2963287A1 (en) * 2014-10-10 2016-04-14 Royal Bank Of Canada Systems and methods of processing electronic payments
WO2016081609A1 (en) * 2014-11-19 2016-05-26 Eyelock Llc Model-based prediction of an optimal convenience metric for authorizing transactions
US10043171B2 (en) * 2014-12-10 2018-08-07 Mastercard International Incorporated System and method for performing automatic payment transactions
US9632664B2 (en) * 2015-03-08 2017-04-25 Apple Inc. Devices, methods, and graphical user interfaces for manipulating user interface objects with visual and/or haptic feedback
GB2537393B (en) * 2015-04-15 2019-07-03 Spice Richard Contactless payment terminal
US10263779B2 (en) * 2015-09-24 2019-04-16 Jonetix Corporation Secure communications using loop-based authentication flow
US10510077B2 (en) * 2016-05-03 2019-12-17 Facebook, Inc. Facial recognition identification for in-store payment transactions
WO2018112525A1 (en) * 2016-12-19 2018-06-28 Xard Group Pty Ltd Digital transaction system and method with a virtual companion card
FR3062008B1 (fr) * 2017-01-17 2019-05-31 Ingenico Group Procede de transmission de donnees, dispositif et programme correspondant.
US20180336548A1 (en) * 2017-05-16 2018-11-22 Google Inc. Nfc-initiated brokered communication

Also Published As

Publication number Publication date
FR3061975A1 (fr) 2018-07-20
CA2992190A1 (fr) 2018-07-17
FR3061975B1 (fr) 2019-10-18
EP3349161B1 (fr) 2023-05-31
US11037186B2 (en) 2021-06-15
US20180204240A1 (en) 2018-07-19
EP3349161A1 (fr) 2018-07-18

Similar Documents

Publication Publication Date Title
ES2904552T3 (es) Método de procesamiento de una transacción a partir de un terminal de comunicación
US20200104837A9 (en) Wireless beacon comunications through magnetic card readers
ES2707370T3 (es) Método de ejecutar transacciones con dispositivos de pago sin contacto que usan operaciones de pre-pulsación y de dos pulsaciones
US11132654B2 (en) Systems and methods for third party payment at point of sale terminals
KR102496877B1 (ko) 전자 지갑 결제시 보안이 강화된 방법으로 와이파이에 자동 접속하는 전자 장치 및 방법
US20150200936A1 (en) System and method for security authentication via mobile device
ES2952773T3 (es) Método de transmisión de datos, dispositivo y programa correspondiente
US20170017952A1 (en) Card registration method for payment service and mobile electronic device implementing the same
CA3076931A1 (en) Adding a credit account to a mobile wallet to make a transaction when the physical card associated with the credit account is unavailable
TW202008220A (zh) 支付二維碼的產生方法和裝置
CA2764558A1 (en) Payment systems and methods using mobile computing devices
EP3762880A1 (en) Instant digital issuance
US20160105760A1 (en) Method and apparatus for information exchange, and delivery terminal
TWI691902B (zh) 應用程式中業務快速啟動方法及裝置和電子設備
ES2952995T3 (es) Método para procesar una transacción de pago, estación de pago y programa correspondiente
US20170372313A1 (en) Electronic device and system for payment
US9959540B2 (en) Security authentication using payment card display devices at accepted merchant locations
CN106471520A (zh) 基于qr图像的装置管理
ES2928446T3 (es) Método de tratamiento de al menos un dato de medio de pago, terminal de pago y programa informático correspondiente
ES2884032T3 (es) Procedimiento de procesamiento de datos de transacción, terminal de comunicación, lector de tarjetas y programa correspondiente
ES2841905T3 (es) Procedimiento de tratamiento de datos en consola multimedia de pago, dispositivos y programas de ordenador correspondientes
ES2626296T3 (es) Procedimiento de multiplexación de mensajes, dispositivo y programa correspondiente
US8369894B1 (en) Confirming certification of combinations of secure elements and mobile devices
ES2865380T3 (es) Método de realización de una transacción, terminal y programa informático correspondiente
JP6756433B2 (ja) データ転送システム及びデータ転送方法