Manual TPV Virtual

La información contenida en el presente documento es CONFIDENCIAL y propiedad de Sistema 4B, S.A., no pudiendo ser distribuida ni utilizada en modo alguno, sin consentimiento previo y por escrito de Sistema 4B, S.A.

MMaannuuaall ddee aacccceessoo aall sseerrvviicciioo

PPAASSAATT IInntteerrnneett 55..33

Versión doc.: 2.5

Fecha: 20/10/2005

PPAASSAATT IINNTTEERRNNEETT 55..33.. MMAANNUUAALL DDEE AACCCCEESSOO AALL SSEERRVVIICCIIOO


ÍNDICE

1 ALCANCE 1 1.1 Modificaciones respecto de la version anterior del Pasat Internet. 1 2 DESCRIPCIÓN GENERAL DEL SISTEMA 2 2.1 Frontal de operaciones on-line 2 2.2 Módulo de configuración 3 2.3 Módulo de administración 4 3 DETALLE DE INTEGRACIÓN CON EL PASAT INTERNET 5 3.1 Transferencia de datos de la compra entre el comercio y Sistema 4B 6 3.1.1 Conexión a Sistema 4B 7 3.1.2 Acceso a información del comercio 7 3.1.3 Pagos periódicos 9 3.2 Comunicación del resultado de una operación al comercio 11 3.2.1 Generación de un fichero al cierre 11 3.2.2 Consulta de operaciones 12 3.2.3 Comunicación ON-LINE del resultado 12 3.3 Comunicación del resultado de una operación al cliente 13 3.4 Página del comercio posterior a la página de recibo del Pasat Internet 14 3.5 Página de recibo alojada en el comercio 14 4 PÁGINAS DE PAGO 15 4.1 Personalización de las páginas de pago 15 4.1.1 Formato de las páginas de pago personalizadas 16 4.1.2 Activación de las páginas de pago personalizadas 20 5 GUÍA DEL MÓDULO DE CONFIGURACIÓN 21 5.1 Configuración en modo simulación. Descripción de parámetros 22 5.2 Paso a producción 24 5.3 Personalización de las páginas de pago 26 5.3.1 Envío de ficheros 26 5.4 Configuración en modo producción 27 6 GUÍA DEL MÓDULO DE ADMINISTRACIÓN 28 6.1 Consulta de operaciones 29 6.2 Consulta de totalizaciones 31 6.3 Devoluciones 32 6.4 Ventas manuales 34 6.5 Descarga de operaciones 34 6.6 Cerrar una totalización abierta 35 6.7 Gestión de Usuarios 35 6.7.1 Crear un usuario nuevo 36 6.7.2 Propiedades de un usuario 36 6.7.3 Lista de usuarios 37 6.8 Contraseña personal 37



6.9 Ficheros 38 6.9.1 Ficheros de devoluciones y preautorizaciones 38 6.10 Consulta de log 41 6.11 Estadísticas 41 6.12 Preautorizaciones 42 6.12.1 Petición Preautorizaciones Manuales 42 6.12.2 Confirmación de preautorizaciones 44 6.12.3 Modificación y anulación de preautorizaciones 45 7 PROTOCOLOS SEGUROS: VERIFIED BY VISA Y MASTERCARD SECURECODE 46 7.1 Cómo funcionan 46 7.2 Qué tiene que hacer el comercio 47 7.3 Qué ventajas tiene para el comercio 47 7.4 Modos de página de autenticación: incrustado VS. emergente 47 8 PREAUTORIZACIONES 49 8.1 Qué es una preautorización 49 8.2 Fases de una preautorización 49 9 ANEXOS 51 9.1 ANEXO I 52 9.2 ANEXO I Bis 59 9.3 ANEXO II 60 9.4 ANEXO III 61 9.5 ANEXO IV 62 9.6 ANEXO VI: Descripción del Código de Validación (CVV2/CVC2) 69 9.6.1 ¿Que es el Código de Validación (CVC2/CVV2)? 69


La información contenida en el presente documento es CONFIDENCIAL y propiedad de Sistema 4B, S.A., no pudiendo ser distribuida ni utilizada en modo alguno, sin consentimiento previo y por escrito de Sistema 4B, S.A

Página 1

11 AALLCCAANNCCEE

El objeto del presente documento es describir el servicio Pasat Internet así como la forma de acceder al mismo por parte del comercio. A través de este servicio el comercio podrá soportar pagos mediante SSL o SET.

Se describen las funciones que ofrece el Pasat Internet y los pasos necesarios para integrar el Web del comercio con el servidor de Sistema 4B.

El documento se estructura en las siguientes partes:

1. Descripción general del sistema.

2. Detalle de integración entre el Pasat Internet y el web del comercio.

3. Descripción de las páginas de pago.

4. Guía del Módulo de Configuración.

5. Guía del Módulo de Administración.

6. Ejemplos varios. (Anexo)

11..11 MMOODDIIFFIICCAACCIIOONNEESS RREESSPPEECCTTOO DDEE LLAA VVEERRSSIIOONN AANNTTEERRIIOORR DDEELL PPAASSAATT

IINNTTEERRNNEETT..

La última versión del Pasat Internet incorpora las siguientes modificaciones:

Incorporación de la nueva función de Preautorizaciones. Este nuevo tipo de operación permite comprobar que una tarjeta de crédito existe, es válida, operativa y tiene saldo suficiente para una operación de venta, a la vez que bloquea una cantidad de saldo, sin generar en ese momento el cargo en firme al cliente. Posteriormente, en un tiempo máximo determinado, el comercio puede confirmar la operación de venta indicando el importe exacto definitivo o bien cancelar el bloqueo, liberando el saldo retenido en la tarjeta. Este tipo de operación es útil en la venta de bienes al peso, cuando el importe exacto de la venta no se conoce en el momento del pedido, y también en operaciones en las que el comerciante no realiza el cargo de la venta al cliente en el momento del pedido, sino una vez que ha verificado el stock del que dispone y por tanto el importe real de la mercancía a entregar. Consulte el Capítulo 8. Preautorizaciones para más información.



Página 2

22 DDEESSCCRRIIPPCCIIÓÓNN GGEENNEERRAALL DDEELL SSIISSTTEEMMAA

En primer lugar hay que destacar que toda la funcionalidad de pago queda centralizada en Sistema 4B, eliminando por lo tanto la necesidad de realizar complicadas integraciones y desarrollos entre el web del comercio y la aplicación de pago, evitando también su posterior mantenimiento y administración.

El Pasat Internet consta de tres elementos:

1. Frontal de pagos on-line: es la parte software residente en Sistema 4B que interactúa con el web del comercio en el momento de una transacción de pago. Es el que muestra al usuario las páginas de pago donde el usuario/cliente teclea los datos de su tarjeta.

2. Módulo de configuración: pequeña aplicación web donde se configuran los principales parámetros que afectan a la integración del Pasat Internet con un comercio. Es el panel de control donde se configuran las URLs de comunicación, datos de la tienda, cambios de estado de simulación a producción …etc. Actualmente este módulo se ha integrado y es accesible desde el Módulo de Administración.

3. Módulo de administración: aplicación web desde la cual se pueden realizar una gran cantidad de operaciones: devoluciones, consultas de operaciones, consultas de totalizaciones1, ventas manuales, preautorizaciones, gestión de usuarios, cierres…etc.

22..11 FFRROONNTTAALL DDEE OOPPEERRAACCIIOONNEESS OONN--LLIINNEE

Básicamente, realizar una transacción de venta consiste en que cuando se quiere realizar el pago -por ejemplo, mediante un botón de pago en la página web del comercio-, el usuario conecta –es conectado- con el servidor web seguro de Sistema 4B, donde se le presenta un formulario para la introducción de los datos de la tarjeta. Esta página puede estar en varios idiomas e incluso personalizada con el ‘look & feel’ del comercio. Cuando el cliente ha confirmado el pago en las páginas de pago de Sistema 4B, es redirigido al sitio web del comercio.

El comercio tiene que incorporar una página en su servidor Web que se conecte a una URL fijada por Sistema 4B, pasando una serie de parámetros que identifican al comercio y la compra que se está realizando en ese momento. A continuación Sistema 4B obtiene del usuario los datos para realizar el pago –además de otros datos que a la vez solicita al servidor del comercio a modo de validación- y realiza la transacción con los sistemas financieros, informando finalmente del resultado al comercio.

La comunicación del Pasat Internet con el servidor del comercio a la que se ha hecho alusión anteriormente está basada en el protocolo HTTP ó HTTPS. El comercio debe realizar unos pequeños desarrollos -utilizando software como CGIs, ASP o similares- que servirán para responder al

1 Se utiliza el concepto de totalización para referirnos al conjunto de operaciones que el banco abona de una vez en la cuenta del comercio. Normalmente con periodicidad diaria se realizan cierres de sesión (fin de día) que generan totalizaciones que tienen el importe de la suma total de operaciones que se han efectuado en el transcurso del día.



Página 3

Pasat Internet cuando éste le pida datos referentes a una transacción de venta o preautorización que se está produciendo. Estos datos, además de ampliar los datos de la compra que inicialmente se comunican, se utilizan como validación del comercio.

Otro tipo de funcionamiento posible es el modo de pagos recurrentes para subscripciones. La diferencia estriba en que el comercio en el momento de comunicar los datos de la compra puede especificar unos plazos y cantidades, de forma que el Pasat Internet informa al cliente y pide confirmación de las operaciones sucesivas que se realizarán automáticamente en el tiempo. El Pasat Internet generará automáticamente las transacciones periódicas según las indicaciones del comercio.

Para conocer con más detalle la integración con el Pasat Internet consulte el Capítulo 3. Detalle de la integración con el Pasat Internet.

22..22 MMÓÓDDUULLOO DDEE CCOONNFFIIGGUURRAACCIIÓÓNN

El módulo de configuración del comercio (ver Capítulo 5) es una aplicación accesible a través de Internet donde el comercio puede realizar las siguientes operaciones:

1. Asignación de datos de la tienda: Nombre de la tienda, persona de contacto, e-mail …etc.

2. Asignación de datos de la integración: idioma de integración, URL del comercio, URLs de conexión para petición y devolución de datos, activación/desactivación de páginas de pago personalizadas …etc.

3. Personalización de las páginas de pago: las páginas web que el cliente de la tienda ve para introducir los datos de la tarjeta residen en el servidor de 4B, pero son personalizables para adaptarlas a la imagen del comercio. Desde esta opción se pueden instalar de forma remota.

4. Presvisualización de las páginas de pago: puede ver una simulación del aspecto de las páginas de pago que se están mostrando en un momento dado.

5. Paso a Producción (entorno real): El comercio debe integrar su tienda con el Pasat Internet y para ayudarle en este proceso, Sistema 4B dispone de un frontal de simulación de idéntico comportamiento al entorno real, pero donde las operaciones nunca son contables. Permite hacer todo tipo de pruebas. Después de una integración exitosa se puede pasar a entorno de producción.

El módulo de configuración es el primer punto donde el desarrollador de la futura tienda debe dirigirse, para establecer los parámetros que son necesarios antes de empezar a integrar.

Algunos parámetros son asignados por Sistema 4B inicialmente, unos podrán cambiarse y otros no.

Toda tienda virtual siempre se inicia en estado de simulación, es decir, se conectará a un entorno especial para pruebas en desarrollo que no provoca movimientos reales en las operaciones que se efectúen.

Una vez que la integración se haya acometido con éxito se debe solicitar el paso a producción desde el módulo de configuración.



Página 4

Para más información acerca del Módulo de configuración ver el Capítulo 5. Guía del Módulo de configuración.

22..33 MMÓÓDDUULLOO DDEE AADDMMIINNIISSTTRRAACCIIÓÓNN

El módulo de administración del comercio (ver Capítulo 6) es una aplicación accesible desde el web donde el comercio puede realizar las siguientes operaciones:

1. Consulta de operaciones: búsquedas avanzadas de cualquier transacción de venta o devolución que haya realizado el comercio.

2. Consulta de totalizaciones: puede consultarse cualquier totalización, esté o no cerrada.

3. Devoluciones: el comercio puede realizar devoluciones parciales o totales de una venta.

4. Ventas Manuales: existe la posibilidad de realizar ventas manuales introduciendo directamente los datos de la tarjeta y el importe.

5. Preautorizaciones: operaciones para bloquear una determinada cantidad sobre del saldo de una tarjeta, a la vez que se valida la existencia de la misma y su capacidad para realizar la operación. Posteriormente se requiere confirmar la operación para que el cargo al cliente sea definitivo. Desde el módulo de administración se puede realizar preautorizaciones manuales, así como confirmar, modificar o anular las preautorizaciones realizadas. Consulte Capítulo 8 Preautorizaciones para más información.

6. Descarga de operaciones autorizadas: existen ficheros con toda la información de las operaciones de una totalización que el comercio puede descargar para su verificación.

7. Cierre manual de totalización: si se opta por el cierre manual el comercio debe cerrar desde esta opción la totalización.

8. Gestión de usuarios: el módulo de administración permite crear usuarios con diferentes perfiles, donde se puede definir el nivel de acceso a la información y las operaciones posibles.

9. Ficheros de devoluciones: Las devoluciones se pueden realizar por lotes utilizando ficheros creados por el comercio y que se deben cargar en el servidor PI50 desde esta opción.

10. Consulta de log: es un registro que almacena errores y pasos realizados por el Pasat Internet y que ayudan al desarrollador a solucionar problemas en la integración.

11. Estadísticas: acceso a diferentes informes que incluyen gráficos sobre las ventas, devoluciones y ventas inacabadas realizadas.

12. Acceso al Módulo de Configuración: en la actual versión del Pasat Internet se ha integrado el acceso al Módulo de Configuración desde el Módulo de Administración.

Para una información más detallada acerca del Módulo de administración ver Capítulo 6. Guía del Módulo de Administración.



Página 5

33 DDEETTAALLLLEE DDEE IINNTTEEGGRRAACCIIÓÓNN CCOONN EELL PPAASSAATT IINNTTEERRNNEETT

Veamos en detalle el flujo de una transacción con el Pasat Internet. Puede seguir la descripción observando el siguiente gráfico:

1. Paso de parámetros al Pasat Internet: El cliente inicia la transacción cuando pulsa sobre un botón de pagar que se encuentra en una página del comercio. Esta acción desencadena una petición desde navegador del cliente al servidor de Pasat Internet con los datos de identificación del comercio y referencia de la compra.

2. Se solicitan datos del desglose de la compra al comercio: Pasat Internet realiza una conexión con una URL del comercio para obtener los datos completos de la compra. Esta acción es importante para verificar la autenticidad del comercio.

4. El Comercio devuelve los datos del desglose de la compra: el Pasat Internet recibe del comercio los datos de la compra incluido el importe, moneda …etc.



Página 6

5. Se presenta al cliente la página de pago: se piden los datos de la tarjeta del cliente. El cliente rellenará un formulario con sus datos de tarjeta. Si el cliente dispone en su tarjeta de pago seguro Verified by Visa o Mastercard SecureCode el software realizará una llamada para abrir la página de autenticación con el banco/caja del cliente2.

6. Se inicia la transacción: la orden de pago se gestiona a través de las redes financieras y se obtiene un resultado, operación aprobada o rechazada.

7. Se devuelven los datos del resultado de la transacción al comercio: el comercio debe desarrollar un programa CGI o similar para recoger en una URL los datos de confirmación de la compra. De esta forma el comercio conoce si la operación de pago ha resultado satisfactoria o no.

8. Se presenta al cliente la página de recibo: si el pago ha sido realizado se presenta una página a modo de recibo con los datos del pago efectuado. Si no se pudo realizar el pago se comunica ‘operación denegada’. En ambos casos se dispone de un botón para que el cliente pueda proseguir navegando por las páginas del comercio –URL proporcionada por el comercio-. *Si bien éste es el funcionamiento estándar del sistema, existe la posibilidad de que esta página de recibo resida en el servidor del comercio, en cuyo caso el comercio debe diseñarla y alojarla, y finalmente activarla en el Módulo de Configuración.

9. Se enlaza la página de recibo a una URL del comercio -*no aplica si la página del recibo reside en el comercio-. Si el comercio no ha facilitado a Sistema 4B una URL para este fin, se utilizará la URL principal del comercio (home).

33..11 TTRRAANNSSFFEERREENNCCIIAA DDEE DDAATTOOSS DDEE LLAA CCOOMMPPRRAA EENNTTRREE EELL CCOOMMEERRCCIIOO YY

SSIISSTTEEMMAA 44BB

Como se ha indicado en el apartado anterior, la comunicación de la cesta de la compra a Sistema 4B se realizará en dos fases. En la primera –desde la página del comercio en el navegador del cliente-, se suministrará la referencia de la compra y el identificador del comercio como parámetros en el momento de conectarse al servidor de Sistema 4B, y en la segunda –iniciada desde Sistema 4B al servidor del comercio- todo el desglose del carrito de compra.

2 En Verified by Visa/MasterCard SecureCode se autentica al titular de la tarjeta. Esta autenticación la realiza el propio banco emisor de la tarjeta a través de una página que es cargada desde el Pasat Internet. El mecanismo de autenticación más extendido es la petición de una contraseña para el uso de la tarjeta. Para más información consulte el capítulo 7.



Página 7

33..11..11 CCoonneexxiióónn aa SSiisstteemmaa 44BB

Hay que distinguir los estados de simulación y producción del comercio. En fase de pruebas, el comercio estará en simulación, por lo que las direcciones del Pasat Internet a las que debe llamar serán diferentes que en producción, cuando las ventas son reales.

En simulación, el comercio deberá llamar desde su página de pago a la siguiente URL:

"https://tpv2.4b.es/simulador/teargral.exe",

sin embargo en producción, el comercio deberá llamar desde su página de pago a la siguiente URL:

"https://tpv.4b.es/tpvv/teargral.exe",

pasándole en ambos casos con método POST los siguientes parámetros (en este mismo orden, ya que es como los identifica el Pasat Internet):

Referencia de la compra (máx. 256 caracteres)

Clave de comercio (proporcionado por Sistema 4B)

Idioma (opcional): sólo en caso de que el comercio tenga su web desarrollado en varios idiomas, tendrá que pasar este parámetro indicando cual de ellos es el utilizado en ese momento, tal como se indica a continuación (para idiomas adicionales contactar con Sistema 4B):

Idioma Código

Castellano es

Catalán ca

Inglés en

Francés fr

Alemán de

33..11..22 AAcccceessoo aa iinnffoorrmmaacciióónn ddeell ccoommeerrcciioo

Tras recibir la solicitud de conexión del comercio, el Pasat Internet realiza una llamada al servidor del comercio, a un programa –CGI, ASP, PHP…etc- que el comercio debe desarrollar para devolver los datos de la cesta de la compra al servidor de Sistema 4B. Este pequeño desarrollo que el comercio debe realizar se encargará de buscar la información de la compra (por ejemplo accediendo a la base de datos de la tienda) y devolverla como resultado al recibir la petición desde Sistema 4B.

El Pasat Internet pasará dos parámetros al programa del comercio:

order: referencia de la compra

store: nombre abreviado (clave) de la tienda virtual

En respuesta el programa del comercio debe generar una salida que debe incluir:

Importe total de la compra: en euros. Formato: MXXXNNN… Donde XXX es el código de moneda ISO (978 para el euro), y NNN… la cifra del importe. No debe incluir separadores de miles ni comas



Página 8

decimales. El importe en euros debe darse multiplicado por cien, ya que los dos últimos dígitos de la derecha se interpretarán como decimales (céntimos de euro). Por ejemplo: 34,51 Euros M9783451. Si en vez de una operación de venta se quiere solicitar una operación de preautorización se antepondrá el prefijo “PRE” a la cadena de importe especificada. Ejemplo de preautorización 40 Euros → PREM9784000.

Número de registros (ítems) de la cesta de la compra: un número que indica cuantos productos forman la cesta de la compra y vienen descritos a continuación.

Registros de la cesta de la compra: cada registro debe contener los siguientes campos:

- Referencia

- Descripción

- Unidades

- Precio: utilizando el mismo formato que en el importe total de la compra, pero omitiendo el código de moneda

Estos cuatro últimos campos deben repetirse tantas veces como registros haya en la cesta de la compra, si bien el detalle de descripción de estos registros está libremente determinado por el comercio.

Cada dato debe ir en una línea diferente, es decir terminado con el carácter de retorno de carro, sin líneas en blanco ni código HTML.

Ejemplo 1: Suponemos que el Pasat Internet ha recibido la petición del comercio X de la compra de referencia Z, con lo cual realiza una llamada al servidor de comercio para que devuelva el desglose de la compra Z: Compra de un libro “Novelas clásicas Vol.1” con referencia A1345, de 5 Euros y una cinta “VHS- El fin de los días” con referencia A1348, de 7 Euros. Importe total de la compra 12 Euros.

El programa del comercio debería responder:

Ejemplo 2 Petición de preautorización: Suponemos que el Pasat Internet ha recibido la petición del comercio X de la compra de referencia Z, con lo cual realiza una llamada al servidor de comercio

M9781200

2

A1345

Novelas clásicas Vol.1

1

500

A1348

VHS – El fin de los dias

1

700



Página 9

para que devuelva el desglose de la compra Z: Compra de 1 kg. De filetes de ternera, a 15,9 Euros el kilo, importe total a preautorizar 15,9 Euros.

El programa del comercio debería responder:

En este caso, para realizar la venta en firme por el importe final que salga según el pesaje de la mercancía, se debe confirmar la preautorización a través del Módulo de Administración (manualmente o por fichero). Para más información acerca de Preautorizaciones vea Capítulo 8.

Para aclarar las posibles dudas respecto al programa del comercio, se adjuntan dos ejemplos:

Ejemplo de un CGI desarrollado en MS Visual C++ (Ver Anexo I).

Ejemplo de un ASP (Ver Anexo I Bis)

33..11..33 PPaaggooss ppeerriióóddiiccooss

La particularidad de algunos tipos de compras como por ejemplo las subscripciones requieren de una funcionalidad extra en el Pasat Internet y en consecuencia una pequeña diferencia en la integración con el comercio.

Los pagos periódicos son pagos que requieren comunicar datos adicionales al Pasat Internet como la cuantía, las fechas y el número de plazos.

El motor del Pasat Internet desencadenará automáticamente los pagos a lo largo del tiempo. El comercio puede utilizar el Módulo de Administración para realizar un seguimiento.

En los pagos periódicos no es posible utilizar protocolos seguros que requieren de la autenticación on-line del titular.

NOTA: La página de pago para subscripciones no puede ser personalizada.

33..11..33..11 CCoonneexxiióónn aa SSiisstteemmaa 44BB

Es similar a la vista anteriormente en 3.1.1, pero añadiendo un parámetro más (en negrita):

- Referencia de la compra

- Nombre abreviado de la tienda

- Idioma (opcional)

- PaymentType: debe contener el valor ‘suscripcion’.

PREM9781590

1

TE122

1 Kg Ternera

1

1590



Página 10

33..11..33..22 AAcccceessoo aa iinnffoorrmmaacciióónn ddeell ccoommeerrcciioo

Cuando en el paso anterior el Pasat Internet identifica el parámetro PaymentType, espera que el servidor del comercio añada la información de los plazos o cuotas en la entrega del desglose de la cesta que se realiza en este paso.

El formato será igual al descrito en el apartado 3.1.2, añadiendo al final nuevos campos (después de los registros de descripción de los items, en negrita):

Importe total de la compra

Número de registros de la cesta de la compra

Registros de la cesta de la compra

Número de cuotas: indicar el número total de operaciones que se efectuarán a lo largo del tiempo y cuya descripción viene a continuación.

Registros de las cuotas: cada registro debe contener los siguientes campos:

- Fecha de cargo: en formato DDMMAAAA

- Importe de la cuota: utilizando el mismo formato que en el importe total de la compra, pero omitiendo el código de moneda (ver 3.1.2).

Estos dos últimos campos deben repetirse tantas veces como se indique en el campo ‘Numero de cuotas’.

Al igual que en los pagos normales, cada dato debe ir en una línea diferente, es decir terminado con el carácter de retorno de carro, sin líneas en blanco ni código HTML.

Ejemplo: Suponemos que el Pasat Internet ha recibido la petición del comercio X de la compra de referencia Z, con lo cual realiza una llamada al servidor de comercio para que devuelva el desglose de la compra Z: Subscripción por 3 meses a una publicación digital ‘iNet’ con referencia S234, de 20 euros en total, a pagar 10 euros el primer mes (04/04/2001) y 5 euros el resto en fechas 05/05/2001 y 05/06/2001. El programa del comercio debería responder:

M9782000

1

S234

Revista digital iNet

1

2000

3

04052001

1000

05052001

500

05062001

500



Página 11

33..22 CCOOMMUUNNIICCAACCIIÓÓNN DDEELL RREESSUULLTTAADDOO DDEE UUNNAA OOPPEERRAACCIIÓÓNN AALL CCOOMMEERRCCIIOO

Existen varias formas de comunicar al comercio el resultado de la transacción.

Las opciones que están disponibles para todos los comercios son las siguientes:

Generación de un fichero de cierre con todas las operaciones

Consulta de operaciones

Comunicación ON-LINE del resultado

33..22..11 GGeenneerraacciióónn ddee uunn ffiicchheerroo aall cciieerrrree

Tras cada cierre de totalización –normalmente a diario- se genera en el servidor Pasat Internet un fichero que contiene las operaciones contables llevadas a cabo. Este fichero no incluye preautorizaciones, ya que no son operaciones cargadas en firme al cliente. Sólo cuando sean confirmadas las Preautorizaciones se consideran a estos efectos como ventas y así se incluyen en el fichero. Es conveniente que el comercio descargue este fichero y lo use como punto de referencia a la hora de supervisar posibles descuadres –posible consecuencia de un problema en las líneas de comunicación durante la confirmación on-line de una operación-.

El fichero que se genera contiene la información de las transacciones realizadas con éxito, con el siguiente formato:

Nomenclatura: el nombre del fichero está compuesto en sus tres primeras posiciones con el código del comercio y el resto es la fecha de generación del fichero en la forma aaaammddhhmm.txt.

Por cada número de comercio (host) que haya totalizado se guardará la siguiente información. Los campos están separados por comas, y los registros por un retorno de carro (chr(13)+ chr(10)).

REGISTRO DE CABECERA

• Número de comercio

• Número de totalización

• Fecha de generación de totalización (ddmmaaaa)

REGISTROS DE OPERACIONES

• Referencia de la compra

• Importe original de la operación

• Código de moneda del importe original

• Contravalor

• Código de moneda del contravalor

• Código de autorización

• Fecha de la operación (ddmmaaaa)

• Usuario de la operación

• Tipo de operación

REGISTRO DE TOTALES (uno por cada moneda de contravalor)



Página 12

• Código de moneda de contravalor

• Nº de operaciones totales

• Importe total bruto

NÚMERO DE LÍNEAS DEL FICHERO (incluida ésta). Este campo sólo aparece una vez al final de cada fichero.

33..22..22 CCoonnssuullttaa ddee ooppeerraacciioonneess

La consulta de operaciones se realiza por web, mediante el Módulo de Administración del comercio. El acceso a estas páginas se realiza mediante usuario y contraseña. Se podrán consultar las transacciones realizadas utilizando diferentes filtros y búsquedas avanzadas para la presentación de la información. De esta forma el comercio puede comprobar los abonos en su cuenta y sus correspondientes transacciones. Para más información ver Capítulo 6, ‘Guía del Módulo de Administración’.

33..22..33 CCoommuunniiccaacciióónn OONN--LLIINNEE ddeell rreessuullttaaddoo

Esta funcionalidad requiere de sencillos desarrollos por parte del comercio pero facilita la actualización de la base de datos en tiempo real en el servidor del comercio.

La comunicación del resultado se produce en el mismo momento de la ejecución de la transacción: cuando se realiza la transacción3, el Pasat Internet hace llamada a un ejecutable situado en el comercio (mediante una URL que puede ser diferente para transacciones autorizadas y denegadas) al que le pasa los siguientes datos:

DESCRIPCIÓN NOMBRE DE VARIABLE CONTENIDO Resultado de la transacción

result 0->Transacción autorizada

1->Transacción cancelada

2->Transacción fallida

Referencia de la compra

pszPurchorderNum

Fecha de la transacción

pszTxnDate dd/mm/aa

Tipo de transacción

tipotrans SSL/CES4

Nombre abreviado tienda

store (clave, dato aportado por 4B)

Si la operación se efectúa correctamente:

3 A diferencia del resto de pagos, la comunicación On-line en el caso de pagos periódicos sólo se lleva a cabo para el primer plazo y sólo en caso de que coincida con la fecha actual, es decir, si se produce un pago en ese momento. 4 Se ha incorporado el nuevo valor CES para indicar protocolo seguro, y se anula el anterior valor SET que es obsoleto.



Página 13

Código de autorización

pszApprovalCode

Id. de transacción pszTxnID

Si la operación resulta fallida:

Código de error coderror

Descripción de error

deserror

Firma de datos (opcional, debe activarse en Módulo de Configuración):

Firma RSA de los parámetros

MAC Resumen hash de los parámetros enviados.

Utilizando estos datos, el ejecutable desarrollado por el comercio podría actualizar automáticamente la base de datos con la información de la compra realizada en el mismo momento de la realización de la transacción.

Las URLs que son llamadas por el Pasat Internet son las especificadas en el Módulo de configuración bajo el nombre de ‘URL que graba el resultado en la BD (TRANSACCIÓN AUTORIZADA)’ y ‘URL que graba el resultado en la BD (TRANSACCIÓN DENEGADA)’. Según el resultado de la transacción se realiza la llamada a una u otra, pasando los parámetros antes descritos.

Es importante que el comercio valide siempre la dirección IP origen de esta comunicación para verificar que es ciertamente Sistema 4B quién le está confirmando el pago.

Opcionalmente, puede enviarse un último parámetro que permite validar la autenticidad del origen (Sistema 4B). Se trata de un resumen hash RSA del QueryString (parámetros enviados) que es reproducible por el comercio conociendo la clave pública de Sistema 4B y por lo tanto permite verificar su valor, lo que permite validar la integridad de los datos y el origen. Si desea implementar esta característica descargue la documentación específica en el Módulo de Configuración, en la sección Cambiar Configuración, junto al elemento “Activar servicio de envío de MAC”.

Existe la posibilidad (ver Módulo de Configuración) de que en el caso que el Pasat Internet detecte un fallo en la comunicación de un resultado positivo (el cliente ha pagado) al servidor del comercio, se envíe un email de comunicación del pago a una dirección proporcionada por el comercio. No obstante, los errores de comunicación en Internet pueden aducir a múltiples factores y no siempre pueden ser detectados por el Pasat Internet.

33..33 CCOOMMUUNNIICCAACCIIÓÓNN DDEELL RREESSUULLTTAADDOO DDEE UUNNAA OOPPEERRAACCIIÓÓNN AALL CCLLIIEENNTTEE

Cuando se realiza una transacción de pago de una compra, hay 3 posibles resultados:

Transacción ACEPTADA

Transacción CANCELADA

Transacción NO ACEPTADA



Página 14

En la configuración estándar el Pasat Internet devuelve una página de ‘recibo’ donde se comunica al usuario el resultado de la operación, con todos los detalles necesarios para la identificación de la transacción, incluidos la URL del comercio y sus datos identificativos.

Si el comercio decide utilizar su propia página de recibo, el Pasat Internet tras el pago, devolverá el control de la navegación a la página que se haya especificado en la configuración del comercio desde el Módulo de Configuración. Por lo tanto no se comunicará ningún resultado desde Sistema 4B al usuario, siendo responsabilidad del comercio la presentación del resultado a su cliente. Esta configuración aumenta el grado de consistencia de la información en el servidor del comercio respecto de los pagos efectuados por sus clientes.

33..44 PPÁÁGGIINNAA DDEELL CCOOMMEERRCCIIOO PPOOSSTTEERRIIOORR AA LLAA PPÁÁGGIINNAA DDEE RREECCIIBBOO DDEELL PPAASSAATT

IINNTTEERRNNEETT

(Este apartado no es aplicable a los casos en que el comercio decida usar su propia página de recibo).

La página de recibo de la transacción –residente en Sistema 4B- posee un botón Continuar que, por defecto, enlaza con la página home de la web del comercio. Si el comercio lo desea se puede enlazar con otra URL a la que se le pasarán los datos del resultado de la transacción. Esta URL puede asignarse en el Módulo de Configuración del comercio.

Los datos que se pasan a esta URL son exactamente los mismos descritos en el apartado 3.2.3, con el objetivo de que el comercio pueda dar información útil al usuario que acaba de realizar la operación, por ejemplo: ofertas vinculadas, descarga de contenido digital, mensaje de agradecimiento…etc.

33..55 PPÁÁGGIINNAA DDEE RREECCIIBBOO AALLOOJJAADDAA EENN EELL CCOOMMEERRCCIIOO

Para el modo de configuración ‘página de recibo en el servidor del comercio’ el Pasat Internet redirige al navegador del cliente hacia una URL proporcionada por el comercio, una vez se ha realizado la transacción (a continuación de que el cliente pulse en el botón ‘Pagar’).

La URL que es llamada por el Pasat Internet se debe especificar en el Módulo de configuración en el campo con nombre ‘URL de recibo (TRANSACCION AUTORIZADA)’ o ‘URL de recibo (TRANSACCION DENEGADA)’.

Los parámetros que se pasan son los descritos en la sección 3.2.3 de modo que el comercio conoce en ese momento el resultado de la transacción.

El comercio tiene la responsabilidad de presentar una página a modo de recibo o resumen de la compra, con los datos de la compra detallados y donde el cliente encuentre el resultado de la operación.



Página 15

44 PPÁÁGGIINNAASS DDEE PPAAGGOO

La parte del Pasat Internet que interactúa con el cliente titular de la tarjeta son las páginas de pago. Son páginas residentes en el servidor de Sistema 4B y que están securizadas mediante el protocolo SSL.

En estás páginas el cliente debe introducir los datos de su tarjeta en modo SSL.

Si el usuario está habilitado por su banco para comercio electrónico seguro (Verified by Visa/MasterCard SecureCode) el Pasat Internet activará el proceso de autenticación del titular de forma automática. En el caso de tarjetas Visa se utiliza el protocolo seguro 3D Secure, en el cual se presenta pagina (ventana emergente o incrustada, según configuración del Pasat Internet) al titular que le permite autenticar la compra contra su banco emisor de la tarjeta. Con el Pasat Internet el comercio tiene la ventaja de estar al margen de la implementacion técnica de estos protocolos, siendo asumida por Sistema 4B.

En este apartado veremos un ejemplo de las páginas de pago estándar para un comercio que tiene su cuenta de abono en un banco genérico llamado XYZ.

En el momento que el titular pulse el botón de pagar en el web del comercio, se le presentará en el navegador la siguiente página (SSL):

En ella deberá introducir los datos relativos a su tarjeta. Al pulsar en Pagar comenzará la transacción de pago.

En el caso de que el titular disponga de pago seguro para su tarjeta se desencadenan los procesos de autenticación antes citados (ventanas emergentes y petición de password), si bien el aspecto y funcionamiento de dichas ventanas dependerá de cada banco emisor.

44..11 PPEERRSSOONNAALLIIZZAACCIIÓÓNN DDEE LLAASS PPÁÁGGIINNAASS DDEE PPAAGGOO

Esta sección describe una parte opcional del sistema y puede omitir su lectura si lo desea.



Página 16

El comercio puede personalizar las páginas para que sean acordes con el diseño de su web. Debido a que las páginas residen en el servidor de Sistema 4B existen unos mecanismos que permiten administrar el uso de estas páginas. Para ello existe una opción en el Módulo de Configuración que gestiona la carga de las páginas y ficheros a de imágenes, y su verificación (ver Capítulo 5. Guía del Módulo de Configuración). En caso de que las páginas personalizadas estén desactivadas, las páginas de pago que se presentan al cliente son las genéricas del banco con el que ha sido contratado el servicio. La activación/desactivación se realiza desde el Módulo de Configuración.

El comercio que quiera tener sus páginas personalizadas debe crearlas por si mismo, con la posibilidad de usar imágenes propias y siguiendo unas reglas que se explican a continuación.

NOTA: Las páginas personalizadas no se aplican a los pagos periódicos (subscripciones).

Se pueden enviar páginas HTML así como las imágenes que vengan incluidas en ésta. El fichero correspondiente a la página de pago será ubicado en el servidor de Sistema 4B previo chequeo del código y renombrado; por lo tanto el nombre del fichero HTML a enviar es indiferente.

44..11..11 FFoorrmmaattoo ddee llaass ppáággiinnaass ddee ppaaggoo ppeerrssoonnaalliizzaaddaass

Serán páginas HTML estándar en las cuales deben insertarse unos tags o etiquetas específicos del Pasat Internet que serán descritos más adelante. Para la elaboración de estas páginas se recomienda partir de la página estándar de pagos que proporciona Sistema 4B para una mejor comprensión de los conceptos aquí descritos.

Una vez creada la página personalizada con tags por el comercio, se debe instalar (subir) en el servidor mediante la opción de páginas personalizadas del Módulo de Administración. En ese proceso se generará el código HTML definitivo, mediante una compilación y verificación previa.

Hay que tener en cuenta que los tags indican al compilador de páginas de Pasat Internet los lugares donde debe realizarse una sustitución de código, que siempre será responsabilidad de Sistema 4B. Es decir, se incluirá un tag especifico donde se quiera que el Pasat Internet inserte valores que sólo se conocen en tiempo de ejecución (como el importe) o valores que son establecidos desde Sistema 4B (como la URL donde residen las imágenes de los logos de bancos). Puede verse un ejemplo de personalización de páginas y uso de tags en el Anexo.

A continuación se muestra la lista de tags posibles, resaltados en negrita los que son de obligado uso:

@-JSFILE-@: Referencia al fichero en JavaScript de validación de la página de pago. Debe incluirse dentro de una etiqueta html del tipo <SCRIPT>. El objetivo es incluir en la página HTML el código de validación generado por Sistema 4B. Por ejemplo

@-URL ASSETS BANCO-@: Ubicación de las imágenes personalizadas por el banco. Hay que considerarlo como si fuera una ruta (no

<SCRIPT LANGUAGE="JavaScript" SRC="@-JSFILE-@"> </SCRIPT>



Página 17

terminada en ‘/’) y usarlo en las referencias a imágenes y logotipos del banco que aparecen en las páginas estándar. Por ejemplo

@-URL ASSETS COMERCIO-@: Ubicación de las imágenes personalizadas por el comercio (estas imágenes son cargadas por el comercio desde el módulo de administración). Hay que considerarlo como si fuera una ruta (no terminada en ‘/’), en las referencias a las imágenes aportadas por el comercio. Similar uso al anterior.

@-NOMBRE COMERCIO-@: Nombre del comercio. Toma su valor de los campos introducidos por el comercio en el Módulo de configuración. Usando este tag el comercio puede simplificar el mantenimiento de esta páginas, ya que si cambia el valor en el Módulo de configuración, el cambio también se verá reflejado en la página personalizada de pago.

@-URL COMERCIO-@: URL de la web del comercio. Similar tratamiento al anterior.

@-EMAIL COMERCIO-@: email para atención a clientes. Similar al anterior.

@-IDPEDIDO-@: Referencia de la compra. Es obligatorio que aparezca como valor de un campo del formulario (tipo hidden) para que sea pasado como parámetro en el submit del formulario (ver más adelante ‘Reglas básicas’).

@-CURRNAME-@: Nombre de la moneda original de la operación.

@-IMPORIG-@: Importe original (comunicado en tiempo real por el comercio).

@-CONTRAVALOR-@: Moneda del contravalor. Siempre será Euros y sólo aparece cuando la moneda original sea Pesetas. OBSOLETO: Con motivo de la migración al Euro este tag se rechaza al subir las páginas de pago desde el 15/12/2001. Desde esta fecha no es un tag válido.

@-EUROS-@: Contravalor en euros del importe original (siempre que el importe original venga dado en Pesetas). OBSOLETO: Con motivo de la migración al Euro este tag se rechaza al subir las páginas de pago desde el 15/12/2001. Desde esta fecha no es un tag válido.

@-STORE-@: Clave del comercio (nombre abreviado de la tienda). Es obligatorio que aparezca como valor de un campo del formulario (tipo hidden) para que sea pasado como parámetro en el submit del formulario (ver más adelante ‘Reglas básicas’).

@-ANNO1-@ ... @-ANNO7-@: Años correspondientes a la fecha de caducidad de la tarjeta. Deberán incluirse todos los elementos de la lista, desde @-ANNO1-@ hasta @-ANNO6-@. Su uso normal es incluirlos como valores en las listas desplegables para la selección de la fecha de caducidad (año). El PI50 sustituye estos tags por los años activos en tiempo real.

@-CHECKPRIVATES-@: Obligatorio. Reservado 4B. Debe incluirse como el código javascript:

<IMG SRC="@-URL ASSETS BANCO-@/logo.gif">



Página 18

@-CONTROLTAG1-@: Obligatorio. Reservado 4B. Debe incluirse literalmente justo antes del tag html </form> del formulario de datos.

Reglas básicas

La llamada al cgi que realiza la transacción debe hacerse de la siguiente manera (si es en producción)

Para el entorno simulación, la llamada anterior debe ser:

Siempre ha de incluirse un campo hidden de nombre ‘contador’ dentro del formulario cuyo valor sea cero:

Las páginas de pago deberán incluir siempre el logo del banco que corresponda y el logo de Sistema 4B. Si el logo de Sistema 4B ha sido personalizado deberá incluirse en la página de pago de esta forma:

El comercio debe enviar un barra.gif personalizado (aunque sea siempre el mismo) por cada idioma cuando realice las cargas desde el Módulo de administración.

En caso de no estar personalizado se debe referenciar:

<FORM NAME=formssl ACTION="/tpvv/ppissl.exe" METHOD=post onSubmit ='return checkPrivates(this, validateForm(this))'>

<IMG SRC="@-URL ASSETS COMERCIO-@/barra.gif">

<IMG SRC="/tpvv/assets/barra.gif">

<INPUT TYPE="hidden" NAME="contador" VALUE=0>

<FORM NAME=formssl ACTION="/simulador/simul.exe" METHOD=post onSubmit ='return checkPrivates(this, validateForm(this))'>

<SCRIPT>@-CHECKPRIVATES-@</SCRIPT>

<INPUT TYPE=”hidden”NAME=”contador”VALUE=”0”>



Página 19

Siempre deberá incluirse el código JavaScript de validación desarrollado por Sistema 4B:

Para pedir el Código de Validación (CVC2/CVV2) de las tarjetas (codvalid), debe incluirse un campo de entrada de texto con NAME=”codvalid”. La validación del formato del contenido (númerico de 3 a 4 posiciones según tarjeta) es realizada por las rutinas de validación incluidas automáticamente por Pasat Internet, pero no se valida su presencia. Por lo tanto, si se quiere forzar a su introducción por parte del usuario (altamente recomendado), deberá incluirse el código javascript necesario para dicha validación y ejecutarlo antes de realizar el submit.

Adicionalmente se debe incluir una página de ayuda para el usuario acerca del Código de Validación, que puede ser alojada en el servidor del comercio y llamada desde la página o bien puede utilizar a la página de ayuda disponible en las páginas estándar de pago. Para mostrar dicha ayuda invoque a la función javascript InfoCVC2(), por ejemplo:

El código fuente de la función InfoCVC2() que muestra la ventana de ayuda es incluido automáticamente al cargar la página personalizada en el Pasat Internet.

Para mostrar una ventana con AYUDA al Código de Validación, recomendamos incluir justo al lado del campo anterior, el siguiente enlace:

Los datos enviados (por método Post) mediante el formulario deben respetar este orden:

• número de tarjeta

• mes correspondiente a la fecha de caducidad

• año correspondiente a la fecha de caducidad

• código de validación (codvalid)

• código de comercio (@-STORE-@)

• referencia de la compra (@-IDPEDIDO-@)

• contador (0) (descrito anteriormente).

Es obligatorio incluir el tag @-CONTROLTAG1-@ justo antes del tag html </form> del formulario de datos.

<SCRIPT LANGUAGE="JavaScript" SRC="@-JSFILE-@"> </SCRIPT>

<INPUT TYPE=”text”NAME=”codvalid” SIZE=”4” MAXLENGTH=”4”>

<A HREF=””TARGET =”_new”>Ayuda(?)</A>

<A TARGET="cvc2" onClick="InfoCVC2();" style='cursor:hand'> <U>(?) Ayuda</U></A>



Página 20

Ejemplo de página de pago: ver ANEXO.

44..11..22 AAccttiivvaacciióónn ddee llaass ppáággiinnaass ddee ppaaggoo ppeerrssoonnaalliizzaaddaass

Las páginas personalizadas se pueden activar y desactivar en cualquier momento. Si las páginas están desactivadas al cliente le serán presentadas las páginas genéricas del banco.

Para activar o desactivar las páginas personalizadas se debe acceder al Módulo de Configuración. Para más detalle ver Capítulo 5. Guía del Módulo de Configuración.



Página 21

55 GGUUÍÍAA DDEELL MMÓÓDDUULLOO DDEE CCOONNFFIIGGUURRAACCIIÓÓNN

A lo largo de este capítulo describiremos cómo utilizar este módulo para una correcta integración de su tienda virtual con el Pasat Internet.

En la ultima versión del Pasat Internet el acceso al Módulo de Configuración se ha integrado dentro del Módulo de Administración, por lo que podrá utilizar la dirección de acceso del Módulo de Administración y mediante un enlace navegar hasta el módulo de Configuración y viceversa, sin necesidad de volver a identificarse (sólo para el usuario Administrador).

No obstante se mantiene el acceso directo (que será eliminado en próximas versiones) restringido mediante la utilización de usuario y contraseña en la siguiente dirección:

https://tpv.4b.es/config

Sistema 4B proporciona al comercio un usuario/contraseña con el perfil de administrador y será este mismo quien puede acceder al módulo y asignar los parámetros requeridos.

Las opciones disponibles difieren dependiendo del estado del comercio (simulación o producción).

Se dispone de:

Configuración: donde se deben asignar los valores a determinados parámetros requeridos para la integración.

Paso a Producción: (disponible sólo en modo simulación) cuando el desarrollo de la integración se haya concluido, es el momento de empezar a trabajar en entorno real. IMPORTANTE: Una vez en producción no se puede volver a modo simulación. (opción no disponible en producción)

Personalización: Permite cargar las páginas de pago personalizadas (ver Capítulo 4) y las imágenes.

Auditoría: permite visualizar la página de pago activa del comercio, tal y como están siendo vistas por los clientes.



Página 22

55..11 CCOONNFFIIGGUURRAACCIIÓÓNN EENN MMOODDOO SSIIMMUULLAACCIIÓÓNN.. DDEESSCCRRIIPPCCIIÓÓNN DDEE

PPAARRÁÁMMEETTRROOSS

El modo inicial de cualquier tienda es simulación, donde las operaciones que se realicen no tienen valor contable.

La pantalla de configuración en simulación se muestra de la siguiente forma:

Los campos se describen a continuación:

Nombre del comercio: nombre que figura en el contrato de prestación del servicio.

Nombre de la tienda virtual: nombre comercial de la tienda, figurará en las páginas de pago que verán los clientes.

Clave del comercio: nombre abreviado asignada por Sistema 4B al comercio. Se usa como parámetro (store) en la integración con el front-end del Pasat Internet.

Banco: prestador del servicio.

Persona de contacto técnico: nombre de la persona designada por el comercio como interlocutor con Sistema 4B en aspectos técnicos.

Teléfono de contacto técnico: de la persona de contacto.

E-mail de contacto técnico

E-mail de contacto para clientes: aparecerá en las páginas de pago que verán los clientes.

Idioma de integración: el idioma en el que se mostrarán las páginas de pago. Si el comercio va a utilizar varios debe seleccionar el valor ‘XX’.

URL Home: Dirección web de la página principal del comercio. En producción solo es modificable mandando un correo electrónico a cgrcontratació[email protected], identificando el nombre de comercio, número de comercio y la clave de comercio.



Página 23

URL que devuelve el desglose de la compra: dirección web del programa del comercio que entrega el desglose de la compra al Pasat Internet (previa petición de éste).

URL que graba el resultado en la BD del comercio (TRANSACCIONES AUTORIZADAS): dirección del programa o página del comercio al cual se le comunicarán los resultados positivos de las operaciones de pago.

URL que graba el resultado en la BD del comercio (TRANSACCIONES DENEGADAS): dirección del programa o página del comercio al cual se le comunicarán los resultados negativos de las operaciones de pago.

URL de continuación posterior a la página de recibo: dirección a la cual el Pasat Internet redirigirá al cliente después de una operación de pago. Puede ser una página de agradecimiento del comercio. Si no se especifica, se utiliza la URL de la home del comercio.

URL de continuación posterior a la página de recibo (WAP): similar al anterior. Sólo para integraciones de WAP.

Activar páginas de pago personalizadas: indica si las páginas personalizadas se muestran al cliente o no (en este caso se mostrarían las páginas estándar del banco).

Páginas de recibo personalizadas: si se activa esta opción el Pasat Internet no mostrará al cliente la página de resultado de la operación (dirigiéndolo directamente a la URL de continuación posterior a la página de recibo), generando una comunicación al comercio y por tanto siendo responsabilidad del comercio la presentación de la página con el resultado de la transacción.

URL de recibo (transacción aceptada): para configuraciones en las que el comercio utiliza su propia página de recibo. En esta dirección se comunicarán los parámetros de los pagos aceptados.

URL de recibo (transacción denegada): para configuraciones en las que el comercio utiliza su propia página de recibo. En esta dirección se comunicarán los parámetros de los pagos denegados.

Grado de conexión: tipo de integración con Pasat Internet.

Fecha de alta en simulación: fecha en la cual Sistema 4B recibe el contrato del comercio y se activa en Pasat Internet – entorno simulación.

Tipo de totalización: indica si el cierre de totalización se hará de forma automática desde Sistema 4B (diario) o de forma manual por el comercio (desde Módulo de administración).

Hora del próximo cierre: para el modo de totalización automática el comercio puede decidir la hora de cierre entre la lista de valores mostrada.

Activación del supervisor de transacciones: si se activa, este servicio genera un email de aviso para los pagos aceptados en los cuales no pudo realizarse la confirmación on-line al servidor del comercio.

E-mail del supervisor de transacciones: obligatorio si se activa este servicio.



Página 24

Activar servicio de envío de MAC: servicio que añade un parámetro extra en las comunicaciones al servidor del comercio que es una firma de los datos de la transacción, de forma que el comercio puede autenticar la integridad de los datos y que el origen es realmente Sistema 4B. La documentación específica de cómo utilizar esta funcionalidad se encuentra en el enlace “Ayuda MAC”. La clave pública de Sistema 4B para esta función puede obtenerla del enlace “Clave RSA de Sistema 4B”.

Modo ventana de autenticación: para los pagos en tiendas virtuales en modo CES (Verified by Visa o MasterCard SecureCode) indica si la página de autenticación del banco que pide la contraseña al comprador, se muestra en una nueva ventana emergente o en la ventana actual del navegador del usuario. Cada vez más se recomienda utilizar la modalidad incrustada para evitar problemas con software de tipo “pop-up killer5” que pueda tener instalado el usuario en su equipo, ya que en estos casos la ventana de autenticación emergente es anulada por dichas aplicaciones y hace que el proceso de pago se quede en espera indefinida. El modo incrustado evita esta situación, aunque la sensación de seguridad al usuario puede ser menor que con ventana emergente, al no ser tan explícito el hecho de que se le está conectando con su banco y la autenticación no es interferida por el comercio. Para más infomación consulte la sección 7.3 Modos de página de autenticación: incrustado VS. Emergente.

Solicita CVC2/CVV2: Indica si se ha de solicitar el Código de Validación de las tarjetas en las páginas de pago (no aplica a páginas de pago personalizadas) y en ventas manuales en el Mod. Admnistración. Si se activa, en las páginas de pago es un dato requerido. En las ventas manuales no es obligatorio rellenarlo, pero es recomendable. Para más información ver el apartado 9.6.

Una vez completado este formulario, el comercio ya puede realizar pruebas con el simulador enlazando su página de pago a la siguiente URL:

“https://tpv2.4b.es/simulador/teargral.exe”

pasando los parámetros descritos en el capítulo “3.1.1. Conexión a Sistema 4B” .

55..22 PPAASSOO AA PPRROODDUUCCCCIIÓÓNN

Cuando el proceso de la integración se haya concluido, es el momento de empezar a trabajar en entorno real.

En producción las ventas generarán cargos reales contra las tarjetas y abonos en la cuenta del comercio.

5 Pop-up killer: Software que el usuario instala en su ordenador y evita que se abran ventanas emergentes de forma automática desde el navegador, pensado para suprimir las ventanas de este tipo que normalmente son de publicidad.



Página 25

Para solicitar el paso a producción utilice la opción mostrada en el Módulo de configuración. Una vez en producción el comercio no puede pasar de nuevo a simulación.

Los parámetros actuales se muestran y se pide confirmación para pasar el comercio a producción con esos parámetros.

IMPORTANTE: Recuerde que antes de pasar a producción deberá redirigir el botón de pago de sus páginas al entorno de producción del Pasat Internet tal y como se indica en el apartado 3.1.1:

"https://tpv.4b.es/tpvv/teargral.exe"

La petición de paso a producción desencadena una serie de procesos en Sistema 4B que finalmente implican normalmente el paso a producción dentro de las siguientes 6 horas. No obstante las modificaciones a la configuración de un comercio en estado de producción son inmediatas.

Como consecuencia del paso a producción se enviará un mensaje a la dirección de e-mail de contacto de la tienda informando de que el paso a producción ha sido realizado.



Página 26

55..33 PPEERRSSOONNAALLIIZZAACCIIÓÓNN DDEE LLAASS PPÁÁGGIINNAASS DDEE PPAAGGOO

El comercio puede utilizar el servicio de administración de páginas personalizadas desde el Módulo de configuración, donde podrá cargar las páginas personalizadas de pago.

Para una descripción sobre la construcción de páginas personalizadas de pago vea la sección 4.1. Personalización de las páginas de pago.

Se debe cargar una página personalizada por cada idioma que use la tienda (así como sus ficheros de imágenes correspondientes).

Para activar las páginas cargadas utilice la opción de ‘Configuración’ antes descrita.

Puede realizar una previsualización de la página de pago activa mediante la opción Auditoría.

55..33..11 EEnnvvííoo ddee ffiicchheerrooss

Se pueden enviar páginas HTML así como las imágenes que vengan incluidas en ésta. El fichero correspondiente a la página de pago será ubicado en el servidor de 4B previo chequeo del código y renombrado; por lo tanto el nombre del fichero HTML a enviar es indiferente.

Para enviar un fichero: escribir el nombre del fichero (path completo), seleccionar el idioma y pulsar el botón ENVIAR FICHERO. El fichero quedará alojado en el servidor de Sistema 4B. Se pueden enviar ficheros en cualquier momento, independientemente de que las páginas personalizadas estén o no activadas.



Página 27

55..44 CCOONNFFIIGGUURRAACCIIÓÓNN EENN MMOODDOO PPRROODDUUCCCCIIÓÓNN

Los parámetros que aparecen son los mismos que en simulación (descritos anteriormente en el apartado 5.1).

Según la opción elegida, podremos visualizar los parámetros actuales de configuración:

O bien modificarlos:



Página 28

66 GGUUÍÍAA DDEELL MMÓÓDDUULLOO DDEE AADDMMIINNIISSTTRRAACCIIÓÓNN

En este capítulo se describe como usar el Módulo de administración servicio para acceder a diversas funciones del Pasat Internet como son las consultas, ventas manuales, devoluciones y cierres manuales. También se dispone de otras opciones como la descarga de operaciones, gestión de usuarios, cambio de contraseña y carga de las páginas de pago personalizadas.

El acceso al Módulo de Administración está restringido mediante la utilización de un usuario y contraseña.

Sistema 4B proporciona al comercio un usuario/contraseña con el perfil de administrador y será este mismo quien, a partir de la opción para tal fin, administre la gestión usuarios y perfiles para su comercio.

La URL de acceso es:

“https://tpv.4b.es/consultas”

Las páginas de consulta están actualizadas con la situación de las operaciones en el momento de tramitar la consulta, permitiendo de este modo que el comercio conozca en tiempo real la situación de las ventas realizadas, pudiendo comprobar si tiene pedidos pendientes de servir, en caso de ser necesario, con la periodicidad que desee.

Otro de los fines de estas páginas es el poder cotejar los abonos realizados en su cuenta, con el detalle de las transacciones correspondientes a ese abono.

Las opciones del Módulo de Administración están estructuradas de la siguiente forma (aunque su visualización y acceso depende de los permisos que tenga el usuario):

Consulta de operaciones

Consulta de totalizaciones

Devoluciones

Ventas manuales

Descarga de operaciones



Página 29

Cerrar (Totalización abierta)

Usuarios (gestión de)

Contraseña personal (no disponible para el administrador)

Ficheros (carga de)

Denegado por c. moneda

Consulta de logs

Estadísticas

Preautorizaciones

El usuario proporcionado por Sistema 4B al comercio tiene privilegios de administrador de la tienda, con la facultad de utilizar cualquier opción disponible (excepto el cambio de contraseña propia), incluyendo la creación y administración de nuevos usuarios.

Puede consultar la ayuda on-line haciendo clic en el icono en cualquier parte del Módulo de administración. Accederá a páginas de ayuda referentes a la función que se esté utilizando.

66..11 CCOONNSSUULLTTAA DDEE OOPPEERRAACCIIOONNEESS

Para realizar la consulta se tienen varios parámetros opcionales de

búsqueda.

Se puede restringir mediante la fecha y hora de las operaciones (desde y hasta), y por tipo de operación (ventas, devoluciones, preautorizaciones…) así como por el modo de pago (CES o SSL).

Como opción de presentación se puede indicar cuantas líneas del resultado de la búsqueda se incluirán en cada página (Nº de operaciones por página).

Introduciendo valores en los cuadros de ‘Búsqueda Avanzada’ puede restringirse mucho más la consulta, como por ejemplo buscando una referencia de compra concreta. El campo referencia admite el uso de caracteres comodín, lo que permite hacer búsquedas por familias de



Página 30

productos, si el comercio lo refleja así en las referencias. Un signo “?”(interrogación) significa “cualquier carácter” y un “*”(asterisco) significa “cualquier secuencia de caracteres”. Así por ejemplo podemos buscar solo las ventas de productos cuya referencia empieza por 5, introduciendo en la casilla referencia el valor 5*.

La opción de incluir línea de totales permite añadir en la página final una línea de resumen de total operaciones y total importe.

El resultado de una búsqueda puede obtenerse en HTML (en el propio navegador), como fichero Excel (lo que le permite trabajar con una hoja excel, hacer graficos,…etc) o en formato texto.

El formato HTML tendrá un aspecto similar a la siguiente figura:

Por cada operación se presenta la siguiente información:

Fecha y hora en que se hizo la transacción.

Código de autorización: Determina que la operación se ha llevado a cabo de forma correcta. Este código se compone de 6 caracteres que se generan aleatoriamente.

Referencia de la compra enviada por el comercio

Tipo (SSL/CES): protocolo utilizado en la operación, es decir, si la transacción se ha realizado utilizando protocolo seguro (CES), o simplemente se han introducido los datos en formulario de páginas de pago (SSL) sin autenticación del titular.

Estado de la operación. Este puede ser:

• Venta: son las operaciones de venta realizadas con éxito. Dependiendo del valor que aparezca en el campo ‘Estado cierre’ son transacciones preparadas para el proceso de totalización y cierre del fin de día (‘Abierto’), o bien son transacciones que ya han sido abonadas porque pertenecen a una totalización que ha sido cerrada (‘Cerrado’).



Página 31

• Devolución: Son operaciones de devolución hechas por el comercio sobre las ventas (una devolución puede ser por un importe diferente al de la venta)

• Preautorización: son peticiones de preautorización aceptadas.

• Preaut-expirada: peticiones de preautorización que han caducado por sobrepasarse el tiempo máximo de vigencia.

• Preaut-anulada : preautorización cancelada por el comercio.

• Venta (Pre): preautorización confirmada y por tanto es como una venta a todos los efectos. Dependiendo del valor que aparezca en el campo ‘Estado cierre’ son transacciones preparadas para el proceso de totalización y cierre del fin de día (‘Abierto’), o bien son transacciones que ya han sido abonadas porque pertenecen a una totalización que ha sido cerrada (‘Cerrado’).

Nº de Cierre: Las operaciones se van agrupando por totalizaciones o cierres. Normalmente cada día, siempre que se realicen operaciones, se cerrará la totalización actual y se creará una nueva, de esta forma consultando por totalización es posible comparar con los abonos que el Banco realiza en la cuenta del comercio.

Importe original: importe de la transacción.

Moneda: moneda en la que se ha realizado la transacción.

Usuario: Indica el usuario que ha realizado la operación. Si la operación se ha realizado desde una tienda virtual o mediante el envío de un fichero de operaciones, el usuario es web. En el caso de que la operación haya sido una venta manual o una devolución, aparecerá el usuario que realizó la operación.

Estado del cierre: Un cierre (totalización) puede tener dos estados: abierto o cerrado. Si el cierre está abierto significa que no se ha tramitado el abono al comercio aún. El proceso de cierre puede ser automático (diario) o manual (por el comercio).

Los resultados aparecen ordenados por la fecha en que se realizó la operación, mostrándose al principio las operaciones más recientes.

66..22 CCOONNSSUULLTTAA DDEE TTOOTTAALLIIZZAACCIIOONNEESS

La consulta de totalizaciones puede restringirse por fechas (desde y hasta) o directamente buscar por un número de cierre conocido.

La lista resultado de totalizaciones se ordena por fecha de cierre,



Página 32

mostrándose primero las más recientes. Pinchando sobre un número de cierre de la lista pasamos a ver los datos de la totalización.

Se muestran agrupadas las operaciones según la moneda utilizada y de igual forma que se abona a la cuenta del comercio.

El importe total bruto es la cifra total de negocio. El importe total neto es el importe que se abonará al comercio y ya lleva descontada la comisión acordada con el banco.

Se puede ver el detalle de todas las operaciones de una operación haciendo clic sobre el enlace ‘Ver desglose de operaciones’. El formato para desglose de operaciones es el mismo descrito para la ‘Consulta de operaciones’.

Si el comercio está configurado para tratar de diferente forma los tipos de tarjeta puede acceder al desglose por tipo de tarjeta mediante el enlace ‘Ver subtotales por tipo de tarjeta’.

66..33 DDEEVVOOLLUUCCIIOONNEESS

Esta opción permite a los comercios hacer devoluciones manuales de las ventas realizadas.

Se permite hacer devoluciones totales o parciales sobre la venta original, siendo el importe máximo a devolver no superior al importe



Página 33

original de la venta + 25% de ésta. Las devoluciones siempre se hacen en la misma moneda que la venta.

Para hacer una devolución lo primero que hay que hacer es localizar la venta original sobre la que se quiere devolver. Para ello se presenta una pantalla en la que el usuario deberá introducir datos en un formulario, con el fin de filtrar las operaciones a presentar (igual que en la consulta de operaciones, apartado 6.1).

El resultado de la búsqueda se muestra como una lista de operaciones donde el último campo a la derecha puede ser un botón de devolución (si la operación lo admite).

Para proceder a la devolución pulsamos el botón de la operación que se desee para presentar un formulario donde se puede especificar la cantidad a devolver.

La petición de devolución permite al comercio hacer una devolución total o parcial de una venta (previamente seleccionada). Se puede hacer más de una devolución sobre una misma venta siempre que la suma de las devoluciones parciales no supere el 125% del importe original de la venta. Como dato informativo se muestra el importe total de las devoluciones realizadas hasta el momento sobre esa venta.

Una vez confirmada la devolución se obtendrá una pantalla con el resultado de la misma (aprobada o rechazada).



Página 34

66..44 VVEENNTTAASS MMAANNUUAALLEESS

Esta opción permite realizar transacciones de venta manuales,

introduciendo los datos de la tarjeta y de la compra según se muestra en la siguiente pantalla. Este tipo de venta se tramita exactamente igual que una venta on-line.

El número de tarjeta no debe contener espacios en blanco. También hay que tener en cuenta que un comercio no puede introducir la misma referencia de compra dos veces en un mismo día.

Después de enviar la venta aparece la página de recibo que indica si la venta ha sido aprobada o rechazada, en la cual se incluye de nuevo el formulario para realizar otra venta.

66..55 DDEESSCCAARRGGAA DDEE OOPPEERRAACCIIOONNEESS

En esta opción el comercio dispone de un listado de ficheros para descarga (normalmente de generación diaria) con las operaciones pertenecientes a cada una de las totalizaciones. Para ver el contenido de un fichero basta con hacer click sobre él.



Página 35

La nomenclatura y el formato de los ficheros han sido descritos en la sección 3.2.1 Generación de un fichero de cierre.

66..66 CCEERRRRAARR UUNNAA TTOOTTAALLIIZZAACCIIÓÓNN AABBIIEERRTTAA

Esta opción permite cerrar una totalización que esté abierta. En esta página aparecen los datos resumen de la totalización a cerrar.

66..77 GGEESSTTIIÓÓNN DDEE UUSSUUAARRIIOOSS

El Módulo de administración está preparado para soportar diferentes niveles de acceso, permitiendo al comercio delegar ciertas funciones a diferentes usuarios.

La gestión de usuarios a la cual tiene acceso a priori el administrador es útil para la creación de nuevos usuarios, asignación o modificación de privilegios …etc.

Las opciones disponibles son:

Crear un usuario nuevo: para añadir un nuevo usuario y definir sus privilegios de acceso.

Propiedades de un usuario: visualiza y permite modificar las propiedades de un usuario existente.



Página 36

Lista de usuarios: muestra una tabla con usuarios y privilegios.

66..77..11 CCrreeaarr uunn uussuuaarriioo nnuueevvoo

Permite dar de alta a un usuario nuevo. Para hacerlo hay identificar al nuevo usuario con su nombre y contraseña, como se muestra en el formulario. El nombre de usuario debe ser distinto de los que ya existan.

La contraseña debe cumplir una serie de requisitos:

Un mínimo de 6 caracteres

Un máximo de 10 caracteres

Al menos un número

Al menos una letra mayúscula

Al menos una letra minúscula

Para determinar el perfil de usuario hay que marcar las casillas que indican si éste podrá acceder a las secciones correspondientes.

66..77..22 PPrrooppiieeddaaddeess ddee uunn uussuuaarriioo

Con esta opción se pueden consultar y modificar las propiedades de un usuario. El usuario se selecciona en una lista desplegable que aparece en pantalla. La pantalla de propiedades es similar a la vista para el alta



Página 37

de usuarios. El cambio de contraseña debe contemplar las reglas anteriormente expuestas.

Para determinar el perfil de usuario hay que marcar las casillas que indican si éste podrá acceder a las secciones correspondientes.

66..77..33 LLiissttaa ddee uussuuaarriiooss

Muestra una tabla con todos los usuarios que están dados de alta y sus propiedades, de forma que de un vistazo se obtiene una percepción general del conjunto de usuarios.

Desde esta vista se pueden realizar cambios de privilegios y contraseñas. El cambio de contraseña debe contemplar las reglas anteriormente expuestas. Para hacer efectivos los cambios es necesario pulsar sobre el icono de grabar situado a la derecha en cada línea.

66..88 CCOONNTTRRAASSEEÑÑAA PPEERRSSOONNAALL

Esta opción (no disponible para el administrador) permite al usuario cambiar su propia contraseña.

La contraseña debe cumplir una serie de requisitos:

Un mínimo de 6 caracteres

Un máximo de 10 caracteres

Al menos un número

Al menos una letra mayúscula



Página 38

Al menos una letra minúscula

66..99 FFIICCHHEERROOSS

El objetivo de esta sección es disponer de un procesador de ficheros, de forma que algunas operaciones de “back-office” puedan realizarse por lotes.

Actualmente se dispone de posibilidad de procesar ficheros de para realizar devoluciones y confirmar o anular preautorizaciones, evitando el tratamiento manual de cada una de ellas. Sin embargo es necesario reseñar la importancia que para el comercio puede tener un mal uso de este servicio, ya que en el caso de las devoluciones se trata de operaciones que descuentan dinero de la cuenta del comercio para abonarlo a clientes.

Otras posibles operaciones de ficheros se irán incorporando en sucesivas fases para su proceso a través de la opción de Ficheros.

66..99..11 FFiicchheerrooss ddee ddeevvoolluucciioonneess yy pprreeaauuttoorriizzaacciioonneess

Procesamiento automatizado de devoluciones y confirmación o anulación de preautorizaciones mediante envío de ficheros. Las preautorizaciones a confirmar o anular han podido generarse desde la integración on-line

(tienda virtual) o mediante la opción de preautorizaciones manuales del Módulo de Administración. Las devoluciones se tramitan igual que las devoluciones manuales.

Introduzca la localización de su fichero directamente en la casilla o utilice el botón ‘Browse’ para seleccionarlo a través del árbol de directorios.

Una vez enviado el fichero, se realiza una verificación previa del formato. Si hubo algún problema en la verificación del formato del fichero se mostrará un mensaje indicando el error y la posición donde se ha encontrado.



Página 39

Si el resultado es satisfactorio se encola el fichero para su proceso definitivo y se muestra el nombre del fichero respuesta que se generará. El nombre estará formado por la fecha y hora de proceso y tendrán la extensión ‘.txt’.

El fichero respuesta puede descargarse desde el enlace ‘Ficheros de respuesta’. En el listado de ficheros de respuesta pueden aparecer ficheros con la extensión ‘.txt.tmp.txt’ que indica que son ficheros que se están generando en ese momento y por tanto son temporales. Habrá que esperar a que el proceso finalice para obtener el fichero definitivo.

66..99..11..11 FFoorrmmaattoo ddeell ffiicchheerroo ddee ddeevvoolluucciioonneess//pprreeaauuttoorriizzaacciioonneess

Tal y como se ha descrito, el sistema acepta un fichero donde figuran las peticiones de devolución, y confirmación o anulación de preautorizaciones, lo procesa y genera un fichero resultado. La estructura de los ficheros de entrada y salida es la misma, pero con la diferencia de que en el fichero resultado algunos campos (que ya existían en el fichero de entrada) contienen información nueva que indican la respuesta del sistema.

El fichero de entrada al sistema se encuentra organizado en registros de tamaño fijo, separados por un Line Feed (LF) y un Carriage Return (CR), formato estándar de texto en el sistema operativo DOS. El fichero comienza con el carácter ‘<’ y termina con el carácter ‘>’.

El fichero de entrada consta de una lista de Registros de Operaciones, cada uno de ellos correspondiente a una operación.



Página 40

REGISTROS DEL FICHERO DE ENTRADA

Campo Longitud Comentarios Nº de comercio 8 El número asignado al comercio en el

contrato del servicio.

Fecha de la operación original

8 Opcional. Formato DDMMAAAA. Si no se facilita han de incluirse blancos.

Obligatorio para preautorizaciones

Referencia de la compra 32 Alineado a la izquierda, completando con blancos por la derecha.

Importe 10 Alineado a la derecha, completando con ceros por la izquierda. Se utiliza el formato original, sin el código de moneda ISO. La devolución siempre es en la moneda original de la venta.

Código de operación 2 ‘05’ : Indica Devolución

‘04’: Confirmación Preautorización

‘13’: Anulación Preautorización

Estado operación 2 ‘00’ : Pendiente de enviar. No procesada aún.

Código de respuesta

2 Blancos.

Texto de respuesta 16 Blancos.

Importante: para devoluciones, si no se especifica la fecha original y hay más de una venta con la misma referencia, la devolución se denegará (es imposible saber a qué cliente corresponde la devolución).

El fichero resultado es similar al de entrada, donde los campos Estado de operación, Código de respuesta y Texto de respuesta contienen valores escritos por Sistema 4B y que indican el resultado de cada operación.

Siendo así, los registros para el fichero de salida serán:

REGISTROS DEL FICHERO DE SALIDA

Campo Longitud Comentarios Nº de comercio 8 El número asignado al comercio en el

contrato del servicio.

Fecha de la operación original

8 Opcional. Formato DDMMAAAA. Si la facilitó el comercio en la entrada.

Obligatorio para preautorizaciones

Referencia de la compra 32 Alineado a la izquierda, completando con blancos por la derecha.

Importe 10 Alineado a la derecha, completando con ceros por la izquierda. Se utiliza el formato original, sin el código de



Página 41

moneda ISO. La devolución siempre es en la moneda original de la venta.

Código de operación 2 ‘05’ : Indica Devolución

‘04’: Confirmación Preautorización

‘13’: Anulación Preautorización

Estado operación 2 ‘00’ : Pendiente de enviar. No procesada aún (por algún problema técnico).

‘01’ : Enviada. (ver campos resultado)

Código de respuesta

2 ‘AA’ : Transacción aceptada (OK) por Sistema 4B.

‘DE’ : Transacción denegada por Sistema 4B.

Texto de respuesta 16 Si la transacción es aceptada contendrá ‘ACEPTADA XXXXXX’,

donde XXXXX es el código de autorización.

En caso de denegación se mostrará el mensaje de error que corresponda a la operación denegada.

Puede ver ejemplos de ficheros en el Anexo.

66..1100 CCOONNSSUULLTTAA DDEE LLOOGG

Como ayuda a la integración en la fase de simulación del comercio, se incluye un listado tipo log de las transacciones y los diferentes pasos que se producen en la comunicación con el servidor del comercio, con información útil para depurar sus desarrollos.

En fase de producción se listan posibles errores producidos en las comunicaciones.

66..1111 EESSTTAADDÍÍSSTTIICCAASS

Esta función permite conocer de un vistazo la progresión de ventas, distribución horaria, por días…etc. Esta opción sólo está disponible cuando el comercio está en producción.

Hay tres tipos básicos de informes:

A) Informe diario: ofrece resultados por días de ventas, devoluciones o ventas inacabadas (el usuario llega hasta la página de pago, pero sale sin acabar la compra).

B) Informe mensual: ofrece resultados por meses de ventas, devoluciones o ventas inacabadas.

C) Informe general (mensual): para un mes determinado muestra a la vez datos comparativos de ventas, devoluciones y ventas inacabadas, con distribución por días de la semana y tramos horarios.



Página 42

66..1122 PPRREEAAUUTTOORRIIZZAACCIIOONNEESS

Esta opción permite:

Realizar preautorizaciones manuales

Modificar preautorizaciones realizadas que estén aún sin confirmar

Anular preautorizaciones realizadas que estén aún sin confirmar

Confirmar preautorizaciones (convertirlas a ventas en firme)

Para saber más acerca del significado y las condiciones de uso de las preautorizaciones consulte el Capítulo 8. Preautorizaciones.

66..1122..11 PPeettiicciióónn PPrreeaauuttoorriizzaacciioonneess MMaannuuaalleess

Esta opción permite realizar transacciones de preautorizacion manuales, introduciendo los datos de la tarjeta y de la compra según se muestra en la siguiente pantalla.

El número de tarjeta no debe contener espacios en blanco. También hay que tener en cuenta que un comercio no puede introducir la misma referencia de preautorización dos veces en un mismo día.

Después de enviar la petición de preautorización aparece la página de recibo que indica si la preautorización ha sido aprobada o rechazada, en



Página 43

la cual se incluye de nuevo el formulario para realizar otra preautorización.



Página 44

66..1122..22 CCoonnffiirrmmaacciióónn ddee pprreeaauuttoorriizzaacciioonneess

Para convertir una preautorización en una venta en firme debe confirmarla por el importe definitiva antes de que la petición de autorización expire.

Para ello acceda a través del botón “Modificar Preautorización” situado en la parte superior derecha de la pantalla de preautorizaciones.

Aquí encontrará un formulario de búsqueda de preautorizaciones. Sobre la lista de resultados podrá seleccionar si quiere modificar, anular o confirmar una preautorización.

Seleccione “Confirmar” la operación que desee y a continuación se le pedirá el importe definitivo, que no debe exceder sobre el importe preautorizado en más de un 15%.



Página 45

66..1122..33 MMooddiiffiiccaacciióónn yy aannuullaacciióónn ddee pprreeaauuttoorriizzaacciioonneess

Se puede modificar el importe de una preautorización, o bien anularla completamente (liberar el saldo retenido a la tarjeta del cliente) a través del botón “Modificar Preautorización” situado en la parte superior derecha de la pantalla de preautorizaciones.

Encontrará un formulario de búsqueda de preautorizaciones. Sobre la lista de resultados podrá seleccionar si quiere modificar, anular o confirmar una preautorización (ver epígrafe 6.12.2 anterior).

Seleccione Modificar o Anular preautorización sobre una operación según desee.



Página 46

77 PPRROOTTOOCCOOLLOOSS SSEEGGUURROOSS:: VVEERRIIFFIIEEDD BBYY VVIISSAA YY MMAASSTTEERRCCAARRDD

SSEECCUURREECCOODDEE

El Pasat Internet es compatible con los nuevos protocolos de pago seguro en Internet propulsados por las marcas Visa Internacional y Mastercard Internacional. Son protocolos establecidos a nivel mundial, por lo que se espera tengan una adopción masiva en el mercado.

En esta sección describiremos en que consisten y como afectan al comercio dichos protocolos.

77..11 CCÓÓMMOO FFUUNNCCIIOONNAANN

En el caso de Visa el protocolo es conocido con el nombre Verified by Visa.

En Mastercard es conocido como MasterCard SecureCode.

El protocolo técnico que subyace en ambos casos es el mísmo, denominado 3D Secure. Iniciamente MasterCard utilizaba una variante denominada SPA Download, pero implicaba la utilización de un componente software a instalar en el PC del cliente, por lo que finalmente se ha decidido potenciar el uso del 3D Secure, que evita dicho requerimiento.

3D Secure es un sistema de pago seguro con tarjeta porque se consigue autenticar al titular de la tarjeta, es decir, garantiza que el cliente que está usando un número de tarjeta es realmente el titular de la misma.

Se trata de poner en contacto al cliente con su banco emisor de la tarjeta en el momento del pago. Al conectar al cliente con su banco, éste puede identificarlo, por ejemplo pidiendo una contraseña asociada a la tarjeta. Sin esta contraseña el pago no sería seguro.

En realidad la forma que tenga el banco emisor de autenticar a su cliente depende de cada banco. Lo que se consigue con el protocolo es establecer una vía común para conectar al titular en el momento de la compra con su banco y que éste proceda a identificarlo.

Así pues, para poder comprar utilizando protocolo seguro, un titular debe estar dado de alta en un ‘Servicio de pago seguro en Internet’ que le ofrecerá su banco para tarjetas Visa y Mastercard (incluyendo tarjetas del grupo, como 4B Mastercard y Maestro).

Para un titular que está registrado con su banco en pago seguro para su tarjeta, el proceso de compra en una tienda compatible con 3D Secure varía ligeramente un pago sin dicho sistema: una vez presentada la página de pago y al introducir el número de tarjeta en el formulario, el cliente verá que una página nueva emerge para conectarle con su banco y le pide una password (o podría ser otro tipo de identificación). Si la password introducida es correcta el proceso de pago sigue normalmente



Página 47

y se cierra la operación. La idea es distraer lo menos posible al titular en el momento del pago, pero poder autenticarlo.

El Pasat Internet al estar preparado con estos protocolos seguros, puede identificar cuando un cliente tiene el servicio de pago seguro, y mediante una serie de conexiones por Internet (paralelas a las establecidas con la tienda) muestra la página que conecta con el banco del titular y que pide a éste que se identifique para autorizar la compra.

77..22 QQUUÉÉ TTIIEENNEE QQUUEE HHAACCEERR EELL CCOOMMEERRCCIIOO

Esta nueva funcionalidad está contemplada en el Pasat Internet y es transparente para el comercio. Sólo hay que tener en cuenta una variación en los valores que puede recibir:

- En las comunicaciones on-line desde el Pasat al servidor del comercio: se añade el valor CES para el parámetro tipotrans, desapareciendo el valor SET. CES indica que la transacción es segura (Comercio Electrónico Seguro)

- Este cambio se refleja también en las consultas de operaciones del módulo de administración, indicándose CES o SSL según sea segura o no segura respectivamente.

77..33 QQUUÉÉ VVEENNTTAAJJAASS TTIIEENNEE PPAARRAA EELL CCOOMMEERRCCIIOO

El hecho de que una transacción sea segura puede implicar según la normativa que esté vigente de Visa y Mastercard y en función del contrato con su banco, que el comercio tenga protección (garantía de pago) frente a los retrocesos del titular en aquellos casos que el titular niega la participación en la compra, sin perjuicio de los derechos del consumidor contemplados en la Ley.

El Pasat Internet siempre identificará con el parámetro tipotrans=CES las transacciones seguras, entendiendo como tales las transacciones en las que el comercio tiene la protección frente al titular descrita en el párrafo anterior.

Las condiciones que determinan cuando una operación es considerada CES (Comercio Electrónico Seguro) pueden variar con el tiempo y la normativa existente, por lo que Sistema 4B se encargará de adaptar el Pasat Internet para que identifique frente al comercio con el indicador CES a aquellas transacciones para las cuales tiene protección.

En resumen, el comercio sólo tiene que fijarse en el valor CES (en el parámetro tipotrans o en la columna Tipo de transaccion en la consulta de operaciones del Módulo de administración) para conocer si una transacción es segura.

77..44 MMOODDOOSS DDEE PPÁÁGGIINNAA DDEE AAUUTTEENNTTIICCAACCIIÓÓNN:: IINNCCRRUUSSTTAADDOO VVSS.. EEMMEERRGGEENNTTEE

La página de autenticación es la página presentada por el banco emisor de la tarjeta al titular cuando una transacción se realiza bajo los protocolos Verified by Visa o Mastercard SecureCode.

Es la página mediante la cual el banco autentica al titular y su tarjeta, normalmente mediante la introducción de una contraseña.

En una fase inicial, esta página se venido mostrado a través de una ventana emergente abierta por el Pasat Internet al usuario, con el



Página 48

objetivo de expresar con mayor claridad al usuario que dicha página está conectándolo con su banco y que por tanto la seguridad y la confidencialidad de la comunicación están garantizadas.

Sin embargo estudios recientes muestran algunas razones por las que se recomienda no utilizar ventanas emergentes para este cometido. Las razones son:

- en los últimos 12 meses la cantidad de publicidad que usa ventanas emergentes como forma de presentación ha crecido considerablemente.

- algunos usuarios confunden la ventana de autenticación con estos anuncios emergentes y cierran la ventana sin siquiera llegar a leer el contenido

- se está haciendo cada vez más popular el uso de utilidades software que bloquean la aparición de ventanas emergentes (pop-up killers), precisamente con la intención de evitar molestos mensajes publicitarios mientras se navega. La utilización de estas aplicaciones bloquearía el proceso de pago al no permitir mostrar la página de autenticación, dejando en espera indefinida el proceso. Algunos navegadores ya lo incluyen como función propia.

Sistema 4B recomienda encarecidamente el uso de la modalidad incrustada para evitar estas situaciones.

Investigaciones a usuarios también apoyan esta recomendación. Vividence Corporation, una compañía de estudios de mercando de Internet, llevó a cabo una estudio para Visa Internacional en Mayo de 2003 con 200 usuarios de Internet desvelando como resultados un alto nivel de facilidad de uso y satisfacción para ambos sistemas (incrustado y emergente), con un 59% de usuarios que expresaron no tener preferencia entre ninguna de las dos modalidades.

Sin embargo para aquellos que expresaron preferencias, un 83% se decantaban de forma absoluta por la modalidad incrustada o en línea6.

En el Pasat Internet, la modalidad de la página de autenticación (incrustada o emergente) es configurable por el comercio, dentro del módulo de configuración. Para saber más acerca del módulo de configuración consulte el capítulo 5.

6 Fuente: Visa International, Mayo 2003.



Página 49

88 PPRREEAAUUTTOORRIIZZAACCIIOONNEESS

En este capítulo describimos las características de este tipo de transacción y las consideraciones a tener en cuenta en su utilización. Es importante que lea y comprenda el funcionamiento de las preautorizaciones para operar con ellas correctamente.

88..11 QQUUÉÉ EESS UUNNAA PPRREEAAUUTTOORRIIZZAACCIIÓÓNN

En ciertas aplicaciones de negocio, el importe definitivo de una venta no se conoce en el momento que el cliente está realizando el pedido. Esto ocurre por ejemplo en la venta de productos sometidos a pesaje.

En tales casos el comercio puede realizar una petición de preautorización, que consiste en solicitar al banco emisor de la tarjeta:

- Comprobar que la tarjeta es válida y activa (existe, no está cancelada, ni caducada, ni en lista negra...)

- Comprobar que tiene saldo suficiente para hacer frente a la operación que se está solicitando.

- Se solicita que temporalmente se bloquee de la disponibilidad del saldo de la tarjeta la cantidad solicitada.

Las preautorizaciones están idealmente concebidas para funcionar con tarjetas de crédito, es decir, tarjetas en las que tiene un saldo disponible del que se van sustrayendo las operaciones de venta sin ser cargado inmediatamente al cliente, y sobre el cual se puede realizar una petición de bloqueo de una cantidad dada (sin cargo inmediato al cliente y por tanto sin que éste reciba adeudo en firme del mismo), que se liberaría automáticamente por el banco emisor de la tarjeta en un plazo determinado de días si el comercio no confirma la operación en firme.

En tarjetas de débito, el sistema intenta reproducir el mismo funcionamiento, es decir solicita al banco emisor de la tarjeta, el bloqueo una cantidad disponible, pero la tarjeta al ser tratada por el banco emisor como débito (cargo inmediato a cuenta) podría ser interpretada por el banco emisor como un cargo en firme y adeudar al cliente en ese momento la cantidad solicitada. La posible consideración de una petición de preautorización como contable por parte del banco emisor de la tarjeta no se sabe a priori, aunque no es un comportamiento estándar y depende de cada emisor.

88..22 FFAASSEESS DDEE UUNNAA PPRREEAAUUTTOORRIIZZAACCIIÓÓNN

El ciclo de vida de una preautorización es el siguiente:

1. Petición de preautorización por parte del comercio. Puede realizarse desde la cesta de la compra (tienda virtual) o de forma manual desde el Módulo de administración (dentro del menú Preautorizaciones). Una preautorización tiene un tiempo de vigencia limitado, que suelen ser varios días. Si transcurre ese tiempo y no se confirma la operación, el banco emisor de la tarjeta procede liberar el saldo retenido y por tanto desaparece el bloqueo. El tiempo



Página 50

estimado por el Pasat Internet como tiempo de caducidad medio es de 10 días desde la petición de preautorización.

2. Opcional. Modificación o anulación de la preautorización. Dentro del plazo de vigencia, el comercio puede modificar el importe de la preautorización para ampliar la cantidad a bloquear o bien anular la preautorización, permitiendo que el importe bloqueado se libere en la tarjeta. Las funciones de modificación y anulación de una preautorización están disponibles manualmente a través del Módulo de Administración. También es posible anular preautorizaciones a través de fichero.

3. Confirmación de preautorización. Una preautorización pasa a ser una venta en firme y por tanto considerada contable para la tarjeta cuando el comercio solicitita la confirmación de preautorización. Una preautorización debe confirmarse antes de su caducidad y por un importe que no debe diferir en más de un 15% del importe preautorizado. Se puede confirmar una preautorización de forma manual desde el Módulo de Administración, o bien mediante fichero.

Cuando ha finalizado el plazo de validez de una preautorización y no ha sido confirmada por el comercio, el emisor procede a la liberación del saldo bloqueado y por tanto se pierde la garantía de disponer del fondo reservado. Por ello el Pasat Internet no deja confirmar una operación de preautorización que ha agotado el tiempo preestablecido como tiempo de validez de la preautorización (10 días).



Página 51

99 AANNEEXXOOSS



Página 52

99..11 AANNEEXXOO II

CGI de acceso a la información de la cesta de la compra a partir de la referencia.

#include <iostream.h>

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <conio.h>

#include <ctype.h>

#include <time.h>

#include <windows.h>

#include <sql.h>

#include <sqlext.h>

#define LF 10

#define CR 13

#define KEY "ZZZZZZZZZZZZ"

#define DENTRO(x,y,x0,y0,x1,y1) ((x>=x0) && (x<x1) && (y>=y0) && (y<y1))

#define MAX_LINE 500 /* maximum line length */

#define MAX_FIELDS 100 /* maximum number of passed fields */

#define FINAL_CAMBIOS "<!!\t\tF>"

/*****************************

VARIABLES GLOBALES

*************************/

struct name_val{ /* structure to hold form post input */

char *name;

char *val;

};

struct name_val entries[ MAX_FIELDS];

int name_val_index = 0; /* Numero de entradas */

struct{

char search[ MAX_LINE];



Página 53

char replace[ MAX_LINE];

int numline;

} Cambios[ 100];

char *makeword( char *line, char stop)

/* makeword la primera vez y getword las siguientes */

{

int x = 0,y;

char *word = (char *) malloc(sizeof(char) * (strlen(line) + 3));

for(x=0;((line[x]) && (line[x] != stop));x++)

word[x] = line[x];

word[x] = '\0';

if(line[x]) ++x;

y=0;

while(line[y++] = line[x++]);

return word;

}

char x2c( char *what)

/* Convierte de hexadecimal a entero */

{

register char digit;

digit = (what[0] >= 'A' ? ((what[0] & 0xdf) - 'A')+10 : (what[0] - '0'));

digit *= 16;

digit += (what[1] >= 'A' ? ((what[1] & 0xdf) - 'A')+10 : (what[1] - '0'));

return(digit);

}

void unescape_url( char *url)

{

register int x,y;

for(x=0,y=0;url[y];++x,++y) {

if((url[x] = url[y]) == '%') {

url[x] = x2c(&url[y+1]);

y+=2;

}

}

url[x] = '\0';



Página 54

}

void plustospace(char *str)

//Cambia "+" por espacio

{

register int x;

for(x=0;str[x];x++) if(str[x] == '+') str[x] = ' ';

}

int get_form_input_get(void) {

/*

read stdin and convert form data into an array; set a variety of

global variables to be used by other areas of the program. GET METHOD.

*/

int data_size; /* size (in bytes) of POST input */

char aux[ MAX_LINE];

int alguno_en_blanco= 0;

char str_input[ MAX_LINE];

strcpy( str_input, getenv("QUERY_STRING"));

data_size = strlen( str_input);

for(name_val_index=0 ; data_size && str_input[0] ; name_val_index++) {

entries[name_val_index].val = makeword(str_input,'&');

plustospace(entries[name_val_index].val);

unescape_url(entries[name_val_index].val);

entries[name_val_index].name = makeword(entries[name_val_index].val,'=');

strcpy( aux, "\"");

strcat( aux, entries[name_val_index].name);

strcat( aux, "\"");

strcpy( entries[name_val_index].name, aux);

if ( strlen( entries[name_val_index].val) == 0)

alguno_en_blanco= 1;

}

return alguno_en_blanco;

}

void main(void)



Página 55

{

HENV henv;

HDBC hdbc;

HSTMT hstmt;

RETCODE retcode;

UCHAR szreferencia[256], szdescripcion[256];

char sentencia[256];

SDWORD cbid_pedido=0, cbreferencia=SQL_NTS, cbdescripcion=SQL_NTS;

SDWORD cbtotal=0, cbunidades=0, cbprecio=0;

long int szid_pedido=0, sztotal=0, szunidades=0, szprecio=0, i=0;

char miszid_pedido[256];

get_form_input_get(); //Recoge datos de la página HTML

cout << "HTTP-Version:HTTP/1.0" << endl;

cout << "Content-Type:text/html" << endl;

cout << endl;

szid_pedido = atoi(entries[0].val);

retcode = SQLAllocEnv(&henv);

if (retcode == SQL_SUCCESS)

{

retcode = SQLAllocConnect(henv, &hdbc);


{

SQLSetConnectOption(hdbc, SQL_LOGIN_TIMEOUT, 5);

retcode = SQLConnect(hdbc, (UCHAR *)"comercio", SQL_NTS, (UCHAR *)"sa", SQL_NTS, (UCHAR *)"", SQL_NTS);

if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO)

{

retcode = SQLAllocStmt(hdbc, &hstmt);


{

itoa(szid_pedido, miszid_pedido, 10);

strcpy(sentencia, "SELECT total FROM mispedidos WHERE id_pedido = ");



Página 56

strcat(sentencia, miszid_pedido);

retcode = SQLExecDirect(hstmt, (UCHAR *)sentencia, SQL_NTS);


{

retcode = SQLFetch(hstmt);


{

SQLGetData(hstmt, 1, SQL_C_LONG, &sztotal, 0, &cbid_pedido);

cout << sztotal << endl;

}

}

SQLFreeStmt(hstmt, SQL_DROP);

}



{


strcpy(sentencia, "SELECT id_pedido FROM micesta WHERE id_pedido = ");




{

while (TRUE)

{



{

SQLGetData(hstmt, 1, SQL_C_LONG, &szid_pedido, 0, &cbid_pedido);

i++;

}

else

{

break;

}

}

}



Página 57


cout << i << endl;

}



{


strcpy(sentencia, "SELECT referencia, descripcion, unidades, precio FROM micesta WHERE id_pedido = ");




{

while (TRUE)

{



{

SQLGetData(hstmt, 1, SQL_C_CHAR, szreferencia, 255, &cbreferencia);

SQLGetData(hstmt, 2, SQL_C_CHAR, szdescripcion, 255, &cbdescripcion);

SQLGetData(hstmt, 3, SQL_C_LONG, &szunidades, 0, &cbunidades);

SQLGetData(hstmt, 4, SQL_C_LONG, &szid_pedido, 0, &cbprecio);

cout << szreferencia << endl;

cout << szdescripcion << endl;

cout << szunidades << endl;

cout << szid_pedido << endl;

}

else

{

break;

}

}

}


}

SQLDisconnect(hdbc);

}



Página 58

SQLFreeConnect(hdbc);

}

SQLFreeEnv(henv);

}

}



Página 59

99..22 AANNEEXXOO II BBIISS

Código ASP de acceso a la información de la cesta de la compra a partir de la referencia.

<%miorder=Request.QueryString("order")%> <% set OBjdbConnection=Server.CreateObject ("ADODB.Connection") OBJdbConnection.open "comercio","sa" SQLQuery= "SELECT total FROM mispedidos WHERE id_pedido=" & miorder set RSCustomerList=OBJdbconnection.Execute(SQLQuery) t=RSCustomerList("total") mitotal = Trim(t) mitotal = mitotal & chr(10) %> <%= mitotal%> <% SQLQuery= "SELECT referencia FROM micesta WHERE id_pedido=" & miorder set RSCustomerList=OBJdbconnection.Execute(SQLQuery) while not RSCustomerList.EOF numreg = numreg + 1 RSCustomerList.movenext wend minumreg = Trim(numreg) minumreg = minumreg & chr(10) %> <%= minumreg%> <% SQLQuery= "SELECT referencia, descripcion, unidades, precio FROM micesta WHERE id_pedido=" & miorder set RSCustomerList=OBJdbconnection.Execute(SQLQuery) while not RSCustomerList.EOF r=RSCustomerList("referencia") d=RSCustomerList("descripcion") u=RSCustomerList("unidades") p=RSCustomerList("precio") miref = Trim(r) mides = Trim(d) miref = miref & chr(10) mides = mides & chr(10) miuni = u & chr(10) mipre = p & chr(10) RSCustomerList.movenext %> <%= miref%> <%= mides%> <%= miuni%> <%= mipre%> <%wend%>



Página 60

99..33 AANNEEXXOO IIII

ASP de actualización de la Base de Datos del comercio con la información de la transacción realizada.

<%resultado=Request.QueryString("result")%> <%order=Request.QueryString("pszPurchorderNum")%> <%fecha=Request.QueryString("pszTxnDate")%> <%tipotrans=Request.QueryString("tipotrans")%> <%store=Request.QueryString("store")%> <% if resultado = 0 then %> <%codaprobacion=Request.QueryString("pszApprovalCode")%> <%idtrans=Request.QueryString("pszTxnID")%> <% else %> <%coderror=Request.QueryString("coderror")%> <%error=Request.QueryString("deserror")%> <%end if%> <% set OBjdbConnection=Server.CreateObject ("ADODB.Connection") OBJdbConnection.open "comercio","usuario","password" if resultado = 0 then SQLQuery= "UPDATE TABLAOPERACIONES SET fechatrans = '" & fecha & "', codaprobacion = '" & codaprobacion & "', idtrans = '" & idtrans & "' WHERE order = '" & order & "'" else SQLQuery= "UPDATE TABLAOPERACIONES SET fechatrans = '" & fecha & "', coderror = '" & coderror & "' WHERE order = '" & order & "'" end if set RSCustomerList=OBJdbconnection.Execute(SQLQuery) %>



Página 61

99..44 AANNEEXXOO IIIIII

Ejemplo de fichero de devoluciones.

• Fichero de entrada <15009922 2206AAA001 00000100000500 15009922 2206AAA203 00000025500500 15009922220620002206AAA204 00000012250500 1500992201052000RKLM22-IK0Q11 00000022000500 1500992202052000UM11MDES999-IMN 00000012000500 15009922 ACES11-IK0Q61 00000005000600 >

• Fichero de salida 15009922 2206AAA001 00000100000501AAACEPTADA 261290 15009922 2206AAA203 00000025500501AAACEPTADA 261291 15009922220600 2206AAA204 00000012250501DEError formato 1500992201052000RKLM22-IK0Q11 00000022000501AAACEPTADA 265466 1500992202052000UM11MDES999-IMN 00000012000501AAACEPTADA 265467 15009922 ACES11-IK0Q61 00000005000601DEERROR Cod. Op.



Página 62

99..55 AANNEEXXOO IIVV

Código HTML ejemplo de página de pagos personalizada. NOTA: el parámetro <form action> debe cambiarse si la página se utiliza en simulación. <HTML> <HEAD> <META NAME="Author" CONTENT="fmunoz"> <TITLE>Pago SSL </TITLE> </HEAD> <SCRIPT LANGUAGE="JavaScript" SRC="@-JSFILE-@"></SCRIPT> <SCRIPT>@-CHECKPRIVATES-@</SCRIPT> <BODY> <center>  <TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" WIDTH="640"> <TR> <TD valign=CENTER WIDTH="509" HEIGHT="50" Background="@-URL ASSETS BANCO-@/trama.gif"> <font face="Arial" size="5" color="#000080"><B><i> Pago SSL</i><B></font></TD> <TD WIDTH="86" HEIGHT="50" Background="@-URL ASSETS BANCO-@/trama.gif"> <IMG NAME="ppago1" SRC="@-URL ASSETS BANCO-@/telepago.gif" WIDTH="86" HEIGHT="50" BORDER="0"></TD> <TD WIDTH="45" HEIGHT="50" Background="@-URL ASSETS BANCO-@/trama.gif"> <img src="@-URL ASSETS BANCO-@/pixel.gif" width=1 height=1></TD> </TR><TD WIDTH="640" HEIGHT="7"></TD> <Tr> </tr> </table> <IMG SRC="/tpvv/assets/barra.gif"><br> <IMG NAME="ppago6" SRC="@-URL ASSETS BANCO-@/logo.gif" BORDER="0"></TD> <table BORDER="0" CELLPADDING="0" CELLSPACING="0" WIDTH="640"> <TR> <TD WIDTH="640" HEIGHT="7"></TD> </TR> </table> <table BORDER="0" CELLPADDING="0" CELLSPACING="0" WIDTH="461">



Página 63

<tr> <TD ROWSPAN="7" COLSPAN="1" WIDTH="1" HEIGHT="218" bgcolor="#a1a1a1"> <IMG NAME="ppago7" SRC="@-URL ASSETS BANCO-@/pixel.gif" WIDTH="1" HEIGHT="1"></TD> <TD ROWSPAN="1" COLSPAN="2" WIDTH="459" HEIGHT="10"> <IMG NAME="ppago8" SRC="@-URL ASSETS BANCO-@/ppago_8x3.gif" WIDTH="459" HEIGHT="10" ></TD> <TD ROWSPAN="7" COLSPAN="1" WIDTH="1" HEIGHT="218" bgcolor="#a1a1a1"> <IMG NAME="ppago9" SRC="@-URL ASSETS BANCO-@/pixel.gif" WIDTH="1" HEIGHT="1" ></TD> </TR> <TR> <TD ROWSPAN="5" COLSPAN="1" WIDTH="102" HEIGHT="248" align=CENTER BACKGROUND="@-URL ASSETS BANCO-@/trama.gif"> <table cellpadding=0 border=0 WIDTH="102" HEIGHT="246" cellspacing=0 > <tr> <td valign=center align=CENTER><IMG NAME="ppago10" SRC="@-URL ASSETS BANCO-@/tar4b.gif" BORDER="0"> </td></tr> <tr> <td valign=center align=CENTER><IMG NAME="ppago10" SRC="@-URL ASSETS BANCO-@/tarmc.gif" BORDER="0"></td></tr> <tr> <td valign=center align=CENTER><IMG NAME="ppago10" SRC="@-URL ASSETS BANCO-@/tarvisa.gif" BORDER="0"> </td></tr>  </table> </TD> <TD ROWSPAN="1" COLSPAN="1" WIDTH="357" HEIGHT="72" align=center>  <font face="ARIAL" size=3 color="#000080"> <B>@-NOMBRE COMERCIO-@</BR></font> <font face="ARIAL" size=2 color="#000080"> <A HREF="@-URL COMERCIO-@"> @-URL COMERCIO-@</A></font></BR> <font face="ARIAL" size=2 color="#000080"><A HREF=mailto:@-EMAIL COMERCIO-@> @-EMAIL COMERCIO-@</A></B></BR> </font>  </TD> </TR>



Página 64

<TR> <TD ROWSPAN="1" COLSPAN="1" WIDTH="357" HEIGHT="8"> <IMG NAME="ppago11" SRC="@-URL ASSETS BANCO-@/separador.gif" WIDTH="357" HEIGHT="8" BORDER="0"></TD> </TR> <TR> <TD ROWSPAN="1" COLSPAN="1" WIDTH="357" HEIGHT="65" align=center>  <font FACE="ARIAL" size=1 color="#000000"> REF: @-IDPEDIDO-@</BR></font> <font FACE="ARIAL" size=4 color="#C00000"> <B>Importe: @-IMPORIG-@ @-CURRNAME-@</B></font> <BR> </font>  </TD> </TR> <TR> <TD ROWSPAN="1" COLSPAN="1" WIDTH="357" HEIGHT="8"> <IMG NAME="ppago12" SRC="@-URL ASSETS BANCO-@/separador.gif" WIDTH="357" HEIGHT="8" BORDER="0"></TD> </TR> <TR> <TD ROWSPAN="1" COLSPAN="1" WIDTH="357" HEIGHT="93" BGCOLOR="#23245F">  <FORM NAME=formssl ACTION="/tpvv/ppissl.exe" METHOD=post onSubmit ='return checkPrivates(this, validateForm(this))'> <TABLE WIDTH="355" BORDER=0 CELLSPACING=0 CELLPADDING=2 > <TR> <TD ALIGN=RIGHT> <font face="ARIAL" size=3 color="#FAAD00"> <B>Número de tarjeta:</B></FONT> </TD> <TD ><INPUT TYPE=TEXT NAME=cc_number SIZE=19 MAXLENGTH=19> </TD>



Página 65

</TR><TR> <TD ALIGN=RIGHT><font face="ARIAL" size=3 color="#FAAD00"> <B>Fecha caducidad:</B></FONT> </TD> <TD ><font face="ARIAL" size=2 color="#FAAD00"> <B>Mes:</B></FONT> <SELECT NAME=cc_expmon> <OPTION>01 <OPTION>02 <OPTION>03 <OPTION>04 <OPTION>05 <OPTION>06 <OPTION>07 <OPTION>08 <OPTION>09 <OPTION>10 <OPTION>11 <OPTION>12 </SELECT> <font face="ARIAL" size=2 color="#FAAD00"> <B>Año:</B></FONT> <SELECT NAME=cc_expyear> <OPTION>@-ANNO1-@</OPTION> <OPTION>@-ANNO2-@</OPTION> <OPTION>@-ANNO3-@</OPTION> <OPTION>@-ANNO4-@</OPTION> <OPTION>@-ANNO5-@</OPTION> <OPTION>@-ANNO6-@</OPTION> <OPTION>@-ANNO7-@</OPTION> </SELECT></B> </TD></TR> <TR> <TD ALIGN=left><font face="ARIAL" size=3 color="#FAAD00"><B> CodValid:</B></FONT></TD> <TD><INPUT TYPE=TEXT NAME="codvalid" SIZE=4 MAXLENGTH=4><font face="Arial" size="3" color="#FAAD00"><A TARGET="cvc2" onClick="InfoCVC2();" style='cursor:hand'> <U>(?) Ayuda</U></A></font></TD></TR> </TD></TABLE> </TD> </TR>



Página 66

<TR> <TD ROWSPAN="1" COLSPAN="4" WIDTH="461" HEIGHT="2" bgcolor="#A1A1A1" > <IMG NAME="ppago13" SRC="@-URL ASSETS BANCO-@/pixel.gif" WIDTH="1" HEIGHT="1" ></TD> </TR> <TR> <TD ROWSPAN="1" COLSPAN="4" WIDTH="461" HEIGHT="5"></TD> </TR> </table> <INPUT TYPE=hidden NAME="store" VALUE="@-STORE-@"> <INPUT TYPE=hidden NAME="ordernum" VALUE="@-IDPEDIDO-@"> <INPUT TYPE=hidden NAME="anular_fpago" VALUE="NO"> <INPUT TYPE=hidden NAME="contador" VALUE=0> <INPUT TYPE="SUBMIT" value=" Pagar " > @-CONTROLTAG1-@ </FORM>  <font face="Arial" size="1" color="#000000">(c) 2001 Sistema 4B, S.A. - Todos los derechos reservados.</font> </center> </BODY> </HTML>



Página 67



Página 69

99..66 AANNEEXXOO VVII:: DDEESSCCRRIIPPCCIIÓÓNN DDEELL CCÓÓDDIIGGOO DDEE VVAALLIIDDAACCIIÓÓNN

((CCVVVV22//CCVVCC22))

Desde Sistema 4B siempre estamos trabajando para evolucionar y mejorar los servicios que ofrecemos a nuestros clientes. Uno de los frentes más activos es habilitar mecanismos que nos permitan añadir confianza en las transacciones realizadas a distancia, donde no existe la posibilidad de verificar físicamente la tarjeta utilizada.

En este sentido, el Pasat Internet 4B permite la introducción del campo Código de validación CVV2/CVC2 de las tarjetas, lo que ayuda a tener más garantías acerca de la legitimidad del titular de la tarjeta.

Actualmente la recogida del código de validación en las páginas de pago es opcional, mediante parámetro configurable en el módulo configuración (ver capítulo 5).

99..66..11 ¿¿QQuuee eess eell CCóóddiiggoo ddee VVaalliiddaacciióónn ((CCVVCC22//CCVVVV22))??

Es un código de tres cifras impreso en el reverso de las tarjetas Visa (CVV2) o Mastercard (CVC2). Este número aparece en cursiva en la parte superior del panel de firma en el reverso de la tarjeta. En las tarjetas American Express el código tiene 4 dígitos y va impreso en el frontal de la tarjeta. Gracias a él es posible identificar que la tarjeta es genuina y existe.

Requerir este dato al titular permite anticiparse y reducir el fraude con tarjetas financieras. Todas las tarjetas Mastercard contienen impreso este valor desde 1997, y las Visa deben tenerlo desde Enero de 2001. NOTA: En algunas tarjetas Visa/MasterCard el número de tarjeta impreso en cursiva en el panel de firma no contiene los 16 dígitos (puede haber solo 4), pero siempre estará seguido por el código de validación (el número de 3 cifras de más a la derecha).

Este código no aparece en facturas de venta, ni se almacena (ni debe almacenarse en el comercio) sólo está impreso en la tarjeta, por lo que normalmente su aportación por parte del titular, implica mayor tranquilidad acerca de la legitimidad de la transacción y en cierta forma nos asegura que la tarjeta está en sus manos.



Página 70

Actualmente es opcional, pero la tendencia a futuro indica que será requisito imprescindible para autorizar una transacción de venta donde no exista lectura de banda o chip. Por ello es muy recomendable que en transacciones donde la tarjeta no está presente físicamente, el comercio pida al titular el código de validación, evitando que usuarios fraudulentos utilicen números de tarjeta robados para realizar compras.

Si el banco emisor de la tarjeta valida dicho código y concluye que es erróneo, la posibilidad de que la transacción sea fraudulenta es muy alta, por lo que se denegará, evitando el fraude y protegiendo al comercio.

Documents

Manual TPV Virtual