MX2012010196A - Procedimiento y sistema para realizar una transaccion. - Google Patents

Procedimiento y sistema para realizar una transaccion.

Info

Publication number
MX2012010196A
MX2012010196A MX2012010196A MX2012010196A MX2012010196A MX 2012010196 A MX2012010196 A MX 2012010196A MX 2012010196 A MX2012010196 A MX 2012010196A MX 2012010196 A MX2012010196 A MX 2012010196A MX 2012010196 A MX2012010196 A MX 2012010196A
Authority
MX
Mexico
Prior art keywords
transaction
image
user
payment
terminal
Prior art date
Application number
MX2012010196A
Other languages
English (en)
Inventor
De La Torre Eduardo Villoslada
Elicegui Javier Martinez
Barrado Pedro Jose Ortega
Original Assignee
Telefonica Sa
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 Telefonica Sa filed Critical Telefonica Sa
Publication of MX2012010196A publication Critical patent/MX2012010196A/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • 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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • 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/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • 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/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/326—Payment applications installed on the mobile devices
    • G06Q20/3265—Payment applications installed on the mobile devices characterised by personalisation for use

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Se describe un procedimiento y sistema para realizar una transacción que comprende los siguientes pasos: facilitar una imagen valida solamente para una determinada transacción (520); mostrar la imagen en una pantalla de un terminal de comunicación de un primer usuario involucrado en la determinada transacción; reconocer la imagen mostrada a través de un terminal de un segundo usuario involucrado en la determinada transacción; verificar la validez de la imagen reconocida (565); y una vez validada la imagen, realizar la determinada transacción (585).

Description

PROCEDIMIENTO Y SISTEMA PARA REALIZAR UNA TRANSACCIÓN CAMPO TÉCNICO DE LA INVENCIÓN La presente invención se refiere al sector de realizar transacciones, y más particularmente a realizar transacciones de pago.
ANTECEDENTES DE LA INVENCIÓN El contexto de los "Point of Sale" (POS) http://en.wikipedia.org/wiki/Point of sale (Terminal punto de Venta que acepta Pagos por Tarjeta) ha estado siempre sujeto a una estricta normativa y vigilancia para que ofreciese las mayores garantías frente a posibles fraudes en los pagos con tarjetas de crédito y debito.
Las diferentes marcas de tarjetas (por ejemplo: VISA, MasterCard, American Express) definen la tecnología y procedimientos bajo los cuales serán aceptados los pagos. Para que un POS sea incorporado como elemento homologado de pago de tarjetas, requiere cumplir toda una serie de normas de carácter físico y software recogidas en los requisitos "PCI Security Standards Council" y EMV (Europay, MasterCard and Visa. Modelo estándar de interoperabilidad para tarjetas de pago con chip incorporado desarrollado por Europay, MasterCard y Visa).
EMV (Europay, MasterCard and Visa) http://en.wikipedia.org/wiki/EMV es un estándar de amplia difusión, desarrollado por la alianza Europay, MasterCard y VISA para la interoperabilidad de las tarjetas chip. Estas tarjetas incorporan un chip como protección frente al fraude que sufren las tarjetas de banda magnética, por ejemplo clonación, captura datos de la banda magnética, sustitución de la firma por un PIN, etc.
La figura 1 muestra un esquema clásico del Proceso de Pago con Tarjetas para el caso de un comercio ubicado en un primer país y un cliente que tiene una tarjeta 10 con un banco emisor 30 de otro país.
Ahora se detallan algunos aspectos a resaltar del proceso de pago a través de tarjeta de crédito/debito. Los POS 20 están conectados a una entidad financiera 40 adquiriente ("Acquirer Bank") que se encarga de tramitar las transacciones del POS. El comerciante dispone de cuenta bancaria donde se depositan los pagos. Las tarjetas de crédito/debito 10 de los usuarios pagadores están asociadas a una cuenta bancaria de un banco emisor ("Issuer Bank") donde se adeudan los importes de los pagos. Dependiendo de si la tarjeta es debito o crédito, el cargo es inmediato o se aplaza un periodo de tiempo (la entidad financiera 30 anticipa el importe al comerciante a modo de préstamo hacia el usuario de la tarjeta). Cada vez que se realiza un pago con una tarjeta, el POS se comunica con entidades intermediarias entre bancos, representadas por la Capa de Servicios de Procesamiento ("Processing Services Layer"), 50 encargada de reconducir la transacción hasta el banco emisor 30 de la tarjeta (Payment Switch function / Redirigir Pagos) y de dar fe del resultado de la misma (Settiement and Clearinghouse function / Liquidación y Compensación ). En ocasiones la Capa de Servicios de Procesamiento se apoya en "International Payment Networks" (Redes de pagos internacionales) 60 (habitualmente gestionadas por infraestructura de las marcas de las tarjetas) para ponerse en contacto con un banco emisor que está en cualquier otro país del mundo.
La introducción del teléfono móvil como medio de pago está revolucionando el mercado de los POS de pequeñas prestaciones, habituales en los pequeños comercios, mercado hasta ahora dominado por pocas marcas como Hypercom, Thales, Ingenico y Verifone. Ejemplos de soluciones basadas en el teléfono móvil son las siguientes: - El teléfono móvil es modificado para incorporar un teclado securizado y/o un lector de tarjeta (opcionalmente impresora externa por Bluetooth). Ejemplo de este tipo de solución es MTT Way Systems o Mophie iPhone credit card reader.
- Los datos de la tarjeta son introducidos manualmente en el teléfono móvil, porque no existe lector de tarjeta, similar a como se realiza en una compra por Internet (ej: ¡Phone application TechFlash).
Un dispositivo con lector de tarjeta e impresora, que se comunica por Bluetooth o por cable con el programa de pago alojado en el teléfono móvil (ej: Intuit GoPayment, Pocket POS Blue Bamboo, EverMobile, CelITreck FirstData, Square ¡Phone Payment System).
Un teclado securizado y un lector de tarjetas conectado al teléfono móvil (ej: HomeATM).
Los principales motivos por los que están surgiendo soluciones de POS basadas en el teléfono móvil que tienden a sustituir a los POS convencionales, son las siguientes: Costes: Los POS actuales son costosos de fabricar y mantener. Sustituirlos por el teléfono móvil de cada persona es una clara forma de reducir costes. Los grandes volúmenes de venta de teléfonos móviles provocan un espectacular dinamismo tecnológico y reducción de costes del que se pueden aprovechar los POS basados en el teléfono móvil.
Usabilidad: A profesionales en movilidad (fontanero, florista, repartidor de pizzas, etc.) les resulta mucho más atractivo aprovechar el propio teléfono móvil como POS y no tener que transportar un voluminoso y pesado POS adicional. Este inconveniente se ve resaltado cuando el volumen de pagos es relativamente pequeño.
Seguridad: Con el nuevo estándar de EMV, la firma como autorización de pago se sustituye por la introducción del PIN. Tener que introducir el PIN personal en los POS de multitud de establecimientos y/o en POS de personas en movilidad que no conocemos, es un elemento de riesgo que se puede reducir si el PIN se introduce en nuestro propio teléfono móvil.
Por otro lado, las soluciones mencionadas anteriormente para adaptar un teléfono móvil como POS tienen aún las siguientes problemáticas: El teléfono móvil que incorpora un teclado securizado y/o un lector de tarjeta, tiene como principal inconveniente el coste de modificar físicamente el teléfono.
En el caso de introducir los datos de la tarjeta manualmente en el teléfono móvil, similar a una compra por Internet, se considera esto un método vulnerable al fraude y lleva consigo mayores comisiones de la operación de pago. Se denomina "Cardholder Not Present Payment" (CNP, Pago con el Titular de la Tarjeta no Presente) al no poder garantizar que el pago es realizado por el propietario de la tarjeta.
- En el caso de usar un dispositivo con lector de tarjeta e impresora, que se comunica con el programa de pago alojado en el teléfono móvil, surge el siguiente problema: el estándar EMV requiere introducir el PIN sobre un teclado securizado físicamente y esta solución no dispone de él. Es considerado también un método vulnerable al fraude (CNP).
- Si se utilizan un teclado securizado y un lector de tarjetas conectado al teléfono móvil, se consigue una solución buena desde el punto de vista de seguridad y costes, pero desde el punto de vista de usabilidad requiere transportar un dispositivo adicional al teléfono móvil, que se puede extraviar, averiar, etc.
La solicitud de patente US 2009/0182634 A1 divulga un procedimiento y sistema para el uso de un medio de pago basado en una imagen almacenada en el teléfono móvil del usuario. La imagen sustituye la tarjeta de crédito o de débito. El usuario enseña la imagen al POS del comerciante para completar una transacción. Se escanea la imagen y se carga la cuenta del usuario con el importe correspondiente. Sin embargo, esta solución también es vulnerable al fraude, ya que un tercero que consigue tener la imagen puede usarla para pagos ilícitos.
BREVE DESCRIPCIÓN DE LA INVENCIÓN Es un objetivo de la invención proporcionar un procedimiento y un sistema correspondiente para mediante los cuales se solucionan al menos una parte de los problemas mencionados anteriormente.
Por tanto, según la invención se proporciona un procedimiento y un sistema según las reivindicaciones independientes. En las reivindicaciones dependientes se definen realizaciones favorables.
La solución de esta invención no requiere de modificaciones físicas del teléfono móvil, no requiere dispositivos adicionales, es económica y puede ser considerada como una solución con un nivel de seguridad muy alto, que garantiza con alto nivel de fiabilidad que el pago es efectuado por el propietario de la tarjeta.
En una realización de esta invención se propone un modelo en el que se paga con el móvil sin requerir llevar consigo las tarjetas de crédito/debito de plástico, y donde el POS es reemplazado por un teléfono móvil.
En esta realización se ha buscado un equilibrio entre seguridad y usabilidad, aprovechando para ello las posibilidades que ofrecen los códigos BIDI y la tecnología OTP. BIDI es un código gráfico bidireccional propiedad de Movistar (http://saladeprensa.telefonica.es/documentos/nprensa/090626 np BIDIS.pdf). OTP (siglas en inglés de "One Time Password") es un modelo de Seguridad donde se genera una contraseña diferente para cada acceso a un recurso protegido (http://en.wikipedia.org/wiki/Qne-time password).
El procedimiento de pago es el siguiente: 1. El usuario pagador se identifica desde su teléfono móvil en la aplicación de pago y solicita un código BIDI-OTP para un pago de un determinado importe. 2. A continuación recibe un BIDI con una validez de un corto periodo de tiempo (ej: 2 min). 3. El comerciante captura con la cámara de su teléfono móvil el BIDI que el usuario pagador le muestra en su teléfono. Para ello el comerciante tiene instalado un programa POS en su teléfono móvil que maneja directamente la cámara. 4. Llega un mensaje al usuario pagador y a la aplicación POS confirmando o rechazando el pago (e-ticket).
Este procedimiento mantiene elevados niveles de seguridad, evitando mostrar ni transmitir datos sensibles (datos de la tarjeta y/o números del teléfono), usando un código BIDI-OTP de un solo uso y utilizando certificados y firmas digitales que protegen tanto las comunicaciones como la aplicación e información almacenada en el teléfono móvil.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención se entenderá mejor y sus numerosos objetivos y ventajas resultarán más evidentes para los expertos en la técnica en referencia a los siguientes dibujos, junto con la memoria descriptiva que los acompaña, en los que: La Figura 1.- Muestra un esquema del proceso de pago con tarjetas de la técnica anterior.
La Figura 2.- Muestra un ejemplo de un código BIDI.
La Figura 3.- Muestra una arquitectura BIDI-OTP según una realización de la invención.
La Figura 4.- Muestra los flujos de instalación de las aplicaciones necesarias para poner en práctica la realización según la figura 3.
La Figura 5.- Muestra los flujos de pago según la realización que muestra la figura 3.
En todas las figuras los mismos números de referencia se refieren a elementos iguales.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN A la vista de las figuras reseñadas, puede describirse aquí una realización práctica de la invención. Se ha diseñado un nuevo esquema de pago para tarjetas de crédito/debito basado en la telefonía móvil y en códigos BIDI-OTP Entendemos por código BIDI-OTP a un código BIDI sólo válido durante una transacción y que caduca transcurrido un breve periodo de tiempo desde su activación. La figura 2 muestra un ejemplo de un código BIDI 200.
En la figura 3 se pueden identificar los elementos de la arquitectura objeto de una realización de la invención. Se trata de: un servidor BIDI-OTP 300 que comprende el software encargado de crear y gestionar los BIDI's durante su tiempo de vida que se les asigna. un servidor de pagos (servidor de transacción) 310, que es la pieza central de la realización. Comprende el software que gestiona y coordinar el proceso de pago, estableciendo la comunicación con el resto de los elementos de la arquitectura. Asimismo, mantiene bajo estrictas medidas de seguridad las bases de datos con la información confidencial de la solución (datos de tarjetas, números de teléfonos, etc). una pasarela de pago 320, que comprende el software encargado de enrutar las transacciones de pago generadas desde la solución POS con BIDI-OTP, hacia las entidades que ofrecen los "Processing Services" (Servicios de procesamiento) sobre diferentes tecnologías de POS.
El servidor de BIDI-OTP 300, el servidor de pagos 310 y la pasarela de pago 320 en conjunto pueden considerarse que ofrecen un nuevo tipo de Servicio de Procesador denominado BIDI-OTP POS.
Además la arquitectura comprende: una aplicación de pago de usuario 330, que es el software instalado en el móvil del usuario pagador. una aplicación POS 340, que es el software instalado en el teléfono móvil del comerciante que incorpora las funciones típicas de un POS.
Redirección de Pagos, Liquidación y Compensación ("Payment Switching, Settlement and Clearinghouse") 350: son los Servicios habituales en los Medios de Pago por Tarjeta, realizados en España por instituciones financieras como SERMEPA, Red 6000, etc. un POS convencional 360, que representa los actuales POS conectados a los Servicios de Redirección, Liquidación y Compensación. una autoridad de certificados 370 ("Certification Authority" (CA)), que es la entidad encargada de emitir los certificados digitales usados en la realización.
Gestor de Confianza de Servicios ("Trusted Service Manager (TSM)") 380: Término generado por GSMA ("GSM Association", Asociación GSM, la asociación que representa los intereses de la industria mundial de telefonía móvil) para denominar a la entidad que tiene las claves de acceso al SIM/UICC (SIM: "Subscriber Identity Module", Módulo de Identidad del abonado; UICC "Universal Integrated Circuit Card" (Tarjeta de Circuito Integrado Universal, es el equivalente a la SIM en UMTS) de los teléfonos móviles y que puede actualizar el software o la información confidencial allí contenida de los diferentes servicios.
Una vez presentados los elementos de la arquitectura, a continuación se describen algunos escenarios típicos.
Para el registro comercial en el servicio de pago por BIDI-OTP, el usuario pagador debe registrarse. Para ello deberá acreditar su identidad y formalizar el contrato legal con sus derechos y obligaciones, bien presencialmente o por algún procedimiento a distancia como hace la banca por Internet.
El comerciante, tal como se hace actualmente, debe solicitar acceso al Servicio de POS, acreditándose y cumpliendo los requisitos legales exigidos por los "Bank Acquirers".
Una vez registrado tanto el usuario pagador como el comerciante, deben instalarse en el teléfono móvil el software de la aplicación, bien descargándoselo por Internet o por otros medios. Por ejemplo, existe también la posibilidad que la operadora instale el programa en la SIM/UICC, bien preinstalado o por actualización usando OTA ("Over The Air"; Procedimiento por el cual las operadoras pueden actualizar la información de las SIM/UICC de los teléfonos a distancia).
Por motivos de seguridad, tanto el software va firmado y las comunicaciones van cifradas a través de certificados digitales. El software del teléfono móvil va firmado con un certificado digital, protegiéndose de esta forma de ser sustituido por software malicioso (troyanos). Además el software tiene acceso a información reservada del servicio almacenada en el SIM/UICC (por ejemplo: clave de uso del servicio BIDI-OTP, lista de tarjetas, limites de pago, etc.) y usa el modulo criptográfico de la SIM/UICC para codificar/decodificar las comunicaciones con el servidor de pagos.
A continuación se describen con ayuda de la figura 4 los flujos de instalación / configuración del servicio BIDI-OTP: 1 - Se registra el servicio BIDI-OTP en la SIM/UICC una vez se ha dado de alta un nuevo usuario pagador/comerciante. 1.1 - El servidor de pagos 310 solicita al TSM 380 actualizar la parametrización del servicio BIDI-OTP en la SIM/UICC (paso 400). 1.2 - El TSM 380 solicita nuevos certificados a la autoridad de certificados 370 (paso 410). 1.3 - El TSM 380 actualiza la información en la SIM/UICC a través de OTA (paso 420). 2 - El usuario pagador/comerciante configura el servicio. 2.1 - Las aplicaciones de pago de usuario 330 o POS 340 acceden a la parametrización del servicio almacenada en la SIM/UICC (paso 430). Asimismo, solicitan al usuario pagador/comerciante la clave de acceso al servicio que es contrastada con la clave almacenada en la SIM/UICC. 2.2 - Una vez el usuario pagador/comerciante introduce sus datos de configuración (por ejemplo aspectos de usabilidad o datos de las tarjetas), los datos no confidenciales son guardados en el almacenamiento no seguro del móvil y los datos confidenciales son encriptados y enviados al servidor de pagos 310 (paso 440). 2.3 - El servidor de pagos 310 accede inicialmente a la autoridad de certificados 370 (paso 450) para obtener la clave pública y desencriptar la información recibida, para a continuación almacenar en su base de datos la información recibida o bien actualizar la información de la SIM/UICC (pasos 400 y 420).
Existe también la opción de acceder a la aplicación de pago de usuario 330/POS 340 de forma remota a través del navegador Web del teléfono móvil. Está opción tiene la ventaja de no tener que instalar la aplicación en el móvil, pero sin embargo es más vulnerable al fraude y requiere disponer de comunicación de datos. Asimismo, en el caso de la aplicación POS se requiere instalar un plug-in para manejar la cámara del teléfono móvil.
A continuación se describen los flujos de pago de la realización con BIDI-OTP con referencia a la figura 5.
El usuario pagador ejecuta la aplicación de pago de usuario 330. La aplicación por seguridad se identifica al usuario/pagador, mostrando información personalizada del servicio almacenada en la SIM/UICC que un programa falso no podría conocer (paso 500).
A continuación se le solicita al usuario pagador la clave de acceso al servicio y los datos del pago (importe, tarjeta, ...). Se puede configurar que pagos de pequeños importe no soliciten clave y tengan asociada una tarjeta por defecto, simplificando la operativa en estos casos.
Se envía al servidor de pagos 310 los datos de pago. Esta información va encriptada y podrá ser enviado por SMS o por comunicación directa a través de Internet (paso 510), según interese en cada caso por las características del teléfono y/o tipo de contrato telefónico del cliente.
El servidor de pagos 310 obtiene del servidor BIDI-OTP un nuevo BIDI con caducidad para un periodo de tiempo limitado (por ejemplo: 2 minutos) (paso 520).
El servidor de pagos 310 envía al teléfono un BIDI-OTP que tiene validez para el pago solicitado (paso 530). Este BIDI puede ser enviado por MMS o bien por comunicación directa con la aplicación de pago de usuario cuando el móvil tiene acceso directo a Internet.
El comerciante ejecuta la aplicación POS 340. Esta aplicación sigue unos procedimientos de seguridad semejantes a los descritos para la aplicación de pago de usuario (paso 540), tales como solicitar clave y mostrar información personalizada del servicio almacenada en la SIM/UICC que un programa falso no podría conocer.
Se muestra la imagen BIDI en la pantalla del móvil del usuario pagador y el comerciante acerca la cámara de su teléfono móvil al teléfono móvil del usuario pagador para reconocer dicha imagen BIDI (paso 550). En situaciones con dificultades para reconocer la imagen BIDI, se puede como procedimiento alternativo, teclear en el POS el número de referencia que acompaña al BIDI-OTP. Este número es también un OTP que no facilita ninguna información confidencial.
La aplicación POS 340 envía encriptada la información del BIDI al servidor de pagos 310 (paso 560). Por motivos de seguridad y usabilidad (hay una secuencia de intercambios de información), esta comunicación preferiblemente no es por MMS o SMS sino por acceso directo de datos a través de Internet.
El servidor de pagos 310 verifica a través del servidor BIDI-OTP 300 la validez del BIDI recibido (paso 565), avisando del error al POS en caso de anomalía.
Una vez validado el BIDI, el servidor de pagos 310 informa a la aplicación POS 340 de las características de la transacción (por ejemplo: Pago/Devolución, importe, etc.) para que el comerciante la acepte/rechace (paso 570).
Una vez aceptada la operación por el comerciante, el servidor de pagos 310 informa a la pasarela de pago 320 de los datos de la tarjeta e importe del pago (paso 580).
La pasarela de pago 320 según las características del pago cursa la transacción al procesador de tarjetas de pago que más interese en cada caso (paso 585). Una vez obtenida respuesta, la pasarela de pago informa al servidor de pagos 310 de la autorización o rechazo del pago (paso 590).
El servidor de pagos 310 informa al usuario pagador del resultado de la transacción y de la referencia del pago (e-ticket) (paso 595). Esta comunicación es por SMS o por comunicación directa a través de Internet, según interese en cada caso por las características del teléfono y/o tipo de contrato telefónico del cliente.
El servidor de pagos 310 informa a la aplicación POS 340 del resultado de la transacción (paso 600).
En el caso de una devolución de pago, el usuario pagador selecciona la opción de aplicación correspondiente a devoluciones, aportando el número de referencia de la transacción a devolver, y el importe asociado.
Esta información de devolución se le comunica al servidor de pagos 310 que verifica si la referencia es correcta y si pertenece a un pago efectuado por la misma referencia de usuario pagador - comerciante. El resto del flujo es semejante al flujo anteriormente descrito para un pago.
Para la consulta/impresión de tickets electrónicos, el usuario pagador y el comerciante pueden acceder vía Web a consultar sus transacciones e imprimir información detallada de las mismas.
Según la realización de la invención descrita se adaptan los actuales teléfonos móviles de usuarios pagadores como un medio de pago para tarjetas de crédito/debito. Esta solución permite a los usuarios realizar pagos de sus tarjetas de crédito/debito a través del teléfono móvil, de una forma similar a los pilotos con NFC ("Near Field Communications". Estándar de comunicación inalámbrica, véase http://en.wikipedia.org/wiki/Near Field Communication) desarrollados por VISA, MasterCard, etc., pero sin necesitar de disponer de un teléfono con tecnología NFC.
Se prevé que el uso masivo de teléfonos móviles con NFC puede prolongarse todavía una serie de años. Esta solución BIDI-OTP es compatible con la solución NFC, de forma que se puede disponer de un POS que acepte tanto pagos por NFC, como BIDI para el parque de teléfonos actuales.
Según la realización de la invención descrita se adaptan los teléfonos móviles de comerciantes como POS. Esta solución permite adaptar por software cualquier teléfono con cámara como POS. El comerciante puede reusar su teléfono como POS sin necesidad de transportar un dispositivo adicional. Esta ventaja se ve resaltada cuando el volumen de pagos es relativamente pequeño.
Se ha puesto especial atención a la usabilidad, ofreciendo un sencillo procedimiento de pago desde teléfonos móviles para el usuario pagador y comerciante.
Esta solución mantiene elevados niveles de seguridad, evitando riesgos de revelar los datos sensibles del usuario pagador y del comerciante, tales como la información de las sus tarjetas y sus números de teléfono. El BIDI-OTP no incorpora ninguna información sobre la tarjeta o teléfono, es únicamente un código temporal que el servidor de pagos sabe asociar a los datos de una transacción.
Además incorpora un esquema de seguridad de factor 2 (A2F), requiriendo disponer de la SIM/UICC y conocer la clave de acceso al servicio. En caso de robo o extravío del teléfono, el servicio no puede ser usado por terceras personas al no conocer la clave del mismo y en caso de conocer la clave no es posible acceder al servicio desde otro teléfono móvil con otra SIM/UICC. En caso de extravío o robo, con el fin de minimizar riesgos, el servicio es fácilmente desactivable y trasladable a otro teléfono móvil (y SIM/UICC) una vez se informe de la incidencia.
Al ser una solución software es una solución fácilmente implantable (time-to-market) y de un bajo coste.
Aunque la invención se ha ilustrado y descrito en detalle en los dibujos y en la descripción anterior, tal ilustración y descripción han de considerarse ilustrativas o ejemplares y no restrictivas; la invención no está limitada a las realizaciones dadas a conocer.
Por ejemplo, se puede utilizar otro tipo de imágenes para un solo uso que las imágenes BIDI.

Claims (30)

R E I V I N D I C A C I O N E S
1. - Un procedimiento para realizar una transacción, caracterizado porque, comprende los siguientes pasos: facilitar una imagen valida solamente para una determinada transacción (520); mostrar la imagen en una pantalla de un terminal de comunicación de un primer usuario involucrado en la determinada transacción; reconocer la imagen mostrada a través de un terminal de un segundo usuario involucrado en la determinada transacción; verificar la validez de la imagen reconocida (565); y una vez validada la imagen, realizar la determinada transacción (585).
2. - El procedimiento de conformidad con la reivindicación 1 , caracterizado porque comprende los pasos de: solicitar la imagen valida solamente para una determinada transacción a través del terminal de comunicación del primer usuario (510); recibir la imagen por el terminal de comunicación (530);
3.- El procedimiento de conformidad con la reivindicación 1 , caracterizado porque la imagen es una representación gráfica bidimensional formada por cuadrículas de igual tamaño.
4.- El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque se envía un mensaje al primer y segundo usuario confirmando o rechazando la transacción (595,600).
5.- El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque se solicitan al primer usuario una clave de acceso y los datos de la determinada transacción (500).
6.- El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque la determinada transacción es un pago o una devolución de pago con tarjeta de crédito o de débito.
7.- El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque el terminal de comunicación es un teléfono móvil, que comprende un elemento seguro para almacenar información reservada del servicio.
8.- El procedimiento de conformidad con la reivindicación 7, caracterizado porque el elemento seguro es una tarjeta SIM o UICC.
9. - El procedimiento de conformidad con la reivindicación 7 ó 8, caracterizado porque se almacena información reservada al servicio de transacción en el servidor de transacción (440) y en el elemento seguro del teléfono móvil (400 y 420).
10. - El procedimiento de conformidad con la reivindicación 9, caracterizado porque la información comprende una o más de: clave de uso de servicio; datos de tarjetas y límites de pago.
11. - El procedimiento de conformidad con cualquiera de las reivindicaciones 7 a 10, caracterizado porque se envían los datos de la transacción a un servidor de transacción (310) de manera encriptada (510), usando el módulo de encriptación del elemento seguro.
12. - El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque el terminal del segundo usuario es un teléfono móvil con cámara y porque se reconoce la imagen mostrada con la cámara.
13. - El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque el terminal del segundo usuario envía los datos de la imagen a un servidor de transacción (310) de manera encriptada (560).
14. - El procedimiento de conformidad con la reivindicación 13, caracterizado porque el servidor de transacción verifica la validez de la imagen reconocida y una vez validada informa al terminal del segundo usuario de las características de la transacción para que el segundo usuario acepte o rechace (570).
15. - El procedimiento de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque como procedimiento alternativo en caso de dificultades para reconocer la imagen, se facilita la introducción de un número de referencia que acompaña a la imagen.
16. - Un sistema para realizar una transacción que comprende un terminal de comunicación de un primer usuario involucrado en una transacción, un terminal de un segundo usuario involucrado en una transacción y un servidor de transacción (310), caracterizado porque el sistema está configurado para: facilitar una imagen valida solamente para una determinada transacción; el terminal de comunicación del primer usuario está configurado para mostrar la imagen en una pantalla; en el que el terminal de usuario de receptor está configurado para reconocer la imagen mostrada; y en el que el sistema está configurado para: verificar la validez de la imagen reconocida; y una vez validada la imagen, realizar la determinada transacción.
17. - El sistema de conformidad con la reivindicación 16, caracterizado porque el terminal de comunicación del primer usuario está configurado para solicitar la imagen al servidor de transacción (310) y recibir la imagen;
18. - El sistema de conformidad con la reivindicación 16 ó 17, caracterizado porque la imagen es una representación gráfica bidimensional formada por cuadrículas de igual tamaño.
19. - El sistema de conformidad con cualquiera de las reivindicación 16 a 8, caracterizado porque está configurado para enviar un mensaje al primer y segundo usuario confirmando o rechazando la transacción.
20. - El sistema de conformidad con cualquiera de las reivindicaciones 16 a 19, caracterizado porque el terminal de comunicación está configurado para solicitar al primer usuario una clave de acceso y los datos de la determinada transacción.
21. - El sistema de conformidad con cualquiera de las reivindicaciones 16 a 20, caracterizado porque la determinada transacción es un pago o una devolución de pago con tarjeta de crédito o de débito.
22. - El sistema de conformidad con cualquiera de las reivindicaciones 16 a 21 , caracterizado porque el terminal de comunicación del primer usuario es un teléfono móvil, que comprende un elemento seguro para almacenar información.
23.- El sistema de conformidad con la reivindicación 22, caracterizado porque el elemento seguro es una tarjeta SIM o UICC.
24.- El sistema de conformidad con la reivindicación 22 ó 23, caracterizado porque el elemento seguro está configurado para el almacenamiento de información reservada al servicio de transacción.
25.- El sistema de conformidad con la reivindicación 24, caracterizado porque la información comprende una o más de: clave de uso de servicio; lista de tarjetas y límites de pago.
26.- El sistema de conformidad con cualquiera de las reivindicaciones 21 a 25, caracterizado porque el terminal de comunicación del primer usuario está configurado para enviar los datos de la transacción a un servidor de transacción (310) de manera encriptada, usando el módulo de encriptación del elemento seguro.
27.- El sistema de conformidad con cualquiera de las reivindicaciones 16 a 25, caracterizado porque el terminal del segundo usuario es un teléfono móvil con cámara para reconocer la imagen mostrada.
28. - El sistema de conformidad con cualquiera de las reivindicaciones 16 a 27, caracterizado porque el terminal del segundo usuario está configurado para enviar los datos de la imagen al servidor de transacción de manera encriptada.
29. - El sistema de conformidad con la reivindicación 28, caracterizado porque el servidor de transacción (310) está configurado para verificar la validez de la imagen reconocida y una vez validada informar al terminal del segundo usuario de las características de la transacción para que el segundo usuario acepte o rechace.
30. - El sistema de conformidad con cualquiera de las reivindicaciones 16 a 29, caracterizado porque el terminal de comunicación del primer usuario está configurado para, como procedimiento alternativo en caso de dificultades para reconocer la imagen, facilitar la introducción de un número de referencia que acompaña a la imagen.
MX2012010196A 2010-03-08 2010-03-08 Procedimiento y sistema para realizar una transaccion. MX2012010196A (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2010/070128 WO2011110697A1 (es) 2010-03-08 2010-03-08 Procedimiento y sistema para realizar una transacción

Publications (1)

Publication Number Publication Date
MX2012010196A true MX2012010196A (es) 2012-10-03

Family

ID=42244338

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2012010196A MX2012010196A (es) 2010-03-08 2010-03-08 Procedimiento y sistema para realizar una transaccion.

Country Status (6)

Country Link
US (1) US20130060697A1 (es)
EP (1) EP2546791A1 (es)
AR (1) AR080464A1 (es)
BR (1) BR112012022785A2 (es)
MX (1) MX2012010196A (es)
WO (1) WO2011110697A1 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013062459A2 (en) * 2011-10-26 2013-05-02 Mopper Ab Method and arrangement for authorizing a user
EP2698755A1 (en) * 2012-08-17 2014-02-19 redpixtec. GmbH Mobile Payment System
US20140279107A1 (en) * 2013-03-14 2014-09-18 William P. Vasquez Systems and methods for integrated, secure point-of-sale transactions
US20160005036A1 (en) * 2014-07-03 2016-01-07 Mistral Mobile Hce token secure delivery without data connectivity
US20170364911A1 (en) * 2014-12-12 2017-12-21 Cryptomathic Ltd Systems and method for enabling secure transaction
TR202003177A2 (tr) * 2020-03-02 2021-09-21 Softpos Teknoloji Anonim Sirketi Yazilim tabanli poslarda kart sahi̇bi̇ni̇ tek kullanimlik şi̇fre i̇le doğrulayan si̇stem ve yöntem

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5726435A (en) * 1994-03-14 1998-03-10 Nippondenso Co., Ltd. Optically readable two-dimensional code and method and apparatus using the same
SE513773C2 (sv) * 1999-03-19 2000-11-06 Ericsson Telefon Ab L M Metod och system för elektronisk handel
EP1410658A2 (en) * 1999-12-03 2004-04-21 First Hop Oy A method and a system for obtaining services using a cellular telecommunication system
JP2001344545A (ja) * 2000-03-29 2001-12-14 Ibm Japan Ltd 処理システム、サーバ、処理端末、通信端末、処理方法、データ管理方法、処理実行方法、プログラム
US7784684B2 (en) * 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
EP1616248A4 (en) * 2003-04-09 2007-11-14 Gtech Corp ELECTRONIC PAYMENT SYSTEM
MX2008012504A (es) * 2006-03-30 2009-05-05 Obopay Inc Sistema movil de pago de persona a persona.
US8793184B2 (en) * 2007-02-12 2014-07-29 Visa U.S.A. Inc. Mobile payment services
US8538819B2 (en) * 2007-07-30 2013-09-17 Ebay Inc. Method and system for dynamic funding
US8249967B2 (en) 2008-01-10 2012-08-21 Park David S Image-based payment medium
EP2558989A1 (en) * 2010-04-13 2013-02-20 Pranamesh Das Secure and shareable payment system using trusted personal device

Also Published As

Publication number Publication date
EP2546791A1 (en) 2013-01-16
US20130060697A1 (en) 2013-03-07
BR112012022785A2 (pt) 2016-06-14
AR080464A1 (es) 2012-04-11
WO2011110697A1 (es) 2011-09-15

Similar Documents

Publication Publication Date Title
CN111357025B (zh) 安全qr码服务
US10922675B2 (en) Remote transaction system, method and point of sale terminal
US20180285875A1 (en) Static token systems and methods for representing dynamic real credentials
US8332323B2 (en) Server device for controlling a transaction, first entity and second entity
RU2242795C2 (ru) Способ осуществления безналичных расчетов и система для осуществления способа
US20160224954A1 (en) Method and system for conducting pre-authorized financial transactions
US8281991B2 (en) Transaction secured in an untrusted environment
US20180268411A1 (en) Apparatus and method for payment authorization and authentication based tokenization
US20130041831A1 (en) Secure and shareable payment system using trusted personal device
US20060016878A1 (en) Wireless payment processing system
KR20160015375A (ko) 모바일 디바이스 기반의 규칙들을 이용한 거래 승인
KR20060022304A (ko) 휴대폰번호 또는 소정의 가상번호를 이용한 쌍방향금융결제 서비스 방법
AU2023200221A1 (en) Remote transaction system, method and point of sale terminal
MX2012010196A (es) Procedimiento y sistema para realizar una transaccion.
Crowe et al. Mobile Phone Technology:“Smarter” Than We Thought
JP2011044151A (ja) 安全な携帯端末支払いのための方法とシステム
US20240135359A1 (en) Payment card, authentication method and use for a remote payment
CA2475275C (en) Wireless data processing system for credit payment
KR20150016649A (ko) NFC(보안 카드)Tag 접촉을 이용한 GPS 안심결제서비스 방법
John METHOD AND SYSTEM FOR SECURE CREDENTIAL GENERATION
EA041883B1 (ru) Система и способ для проведения удаленных транзакций с использованием платежного терминала точки продаж
KR20090002066A (ko) 모바일을 이용한 장기무이자 할부 결제처리 방법과 이를위한 프로그램 기록매체

Legal Events

Date Code Title Description
FA Abandonment or withdrawal