TPV VIRTUAL 5.0 MANUAL DE IMPLEMENTACION PARA COMERCIOS
Confederación Española de Cajas de Ahorros. Avda. de Bruselas, 37 – 28028 Madrid – Tel.: 91 596 53 28 Email:
[email protected]
1
CONTENIDO CONTENIDO ....................................................................................................................................... 2 1.- INTRODUCCIÓN: .......................................................................................................................... 3 Características más importantes: .................................................................................................... 3 2.- POR DÓNDE EMPEZAR: .............................................................................................................. 5 3.- TIPOS DE COMERCIOS: .............................................................................................................. 6 Estándar/Inseguro: .......................................................................................................................... 6 Seguro: ............................................................................................................................................ 6 Mixto: ............................................................................................................................................... 6 4.- ESCENARIOS DE PAGOS:........................................................................................................... 8 Pago en comercio electrónico Estándar/no seguro:........................................................................ 8 Pago en comercio electrónico Seguro (3D-Secure) ...................................................................... 10 5.- CÁLCULO DE LA FIRMA............................................................................................................ 12 6.- PROGRAMACIÓN A REALIZAR EN EL SERVIDOR DE COMERCIO...................................... 14 6.1.- Compatibilidad con versiones anteriores .............................................................................. 15 6.2 Ejemplos de formularios .......................................................................................................... 16 Ejemplo de llamada en la que los datos de tarjeta son solicitados por el TPV ......................... 16 Ejemplo de llamada en la que los datos de tarjeta son solicitados por el comercio.................. 17 6.3 Direcciones de llamada ........................................................................................................... 18 7.- PÁGINAS DE PAGO.................................................................................................................... 19 7.1.- Características de las páginas de pago propias del TPV ..................................................... 19 8.- COMUNICACIÓN ON-LINE ........................................................................................................ 20 Comunicación online con respuesta requerida: ............................................................................ 21 8.1.- Ver y modificar la configuración online actual de su comercio ............................................. 21 9.- CONSULTA ONLINE DE OPERACIONES REALIZADAS: ......................................................... 23 11.- ANULACIÓN DE OPERACIONES............................................................................................. 25 Anulación parcial desde WEB del Comercio. ................................................................................ 27 12.- CONSOLA DE ADMINISTRACIÓN TPV VIRTUAL PARA COMERCIOS................................. 28 Acceso ........................................................................................................................................... 28 Cambio de entorno ........................................................................................................................ 28 Día a Día –Comparar fechas ......................................................................................................... 28 Día a Día –Ver informes diarios..................................................................................................... 29 Listado de operaciones.................................................................................................................. 29 Detalle de una operación............................................................................................................... 30 Anulación de una operación .......................................................................................................... 31 Anulación parcial de una operación .............................................................................................. 31 Pagos periódicos ........................................................................................................................... 31 Operaciones de un pago periódico................................................................................................ 32 Pagos de un pago periódico .......................................................................................................... 33 Pagos directos ............................................................................................................................... 34 Pagos por email............................................................................................................................. 35 Configuración – Datos del comercio.............................................................................................. 36 Configuración – Filtros de compra................................................................................................. 37 Usuarios y perfiles ......................................................................................................................... 38 13.- DIRECCIONES DE SOPORTE TPV ......................................................................................... 39 ANEXO V. TARJETAS DE PRUEBAS.............................................................................................. 40 ANEXO VI. PAGO SEGURO 3D-SECURE. ..................................................................................... 41 ANEXO VIII: TRATAMIENTO DE ERRORES.................................................................................. 45 ANEXO IX: PETICIÓN DE CVV2/CVC2 ........................................................................................... 48 ANEXO X. OPERATORIA MULTIMONEDA ..................................................................................... 49 ANEXO XI: GESTOR DE OPERACIONES....................................................................................... 52 ANEXO XII: OPERATORIA AMEX (AMERICAN EXPRESS)........................................................... 55 PREGUNTAS FRECUENTES........................................................................................................... 58 RECOMENDACIONES. .................................................................................................................... 60 CONTROL DE VERSIONES:............................................................................................................ 61
2
1.- INTRODUCCIÓN: En este documento se describen las características de la versión 5.0 del TPV virtual ofrecido por CECA. Un TPV es un software que se implementa en los SERVIDORES WEB DEL COMERCIO y que permite realizar pagos securizados mediante una tarjeta de crédito/débito en internet. Esta nueva versión es totalmente compatible con las versiones anteriores, por lo que aquellos COMERCIOS que ya estén utilizando el TPV virtual de CECA, podrán continuar haciéndolo sin necesidad de realizar ningún cambio en su programación, a no ser obviamente, que quieran incorporar alguna de las nuevas características. La implementación de un TPV requiere unos conocimientos mínimos de programación, por parte del cliente. Existe otra opción denominada TPV-Blanco que es una aplicación WEB que no se integra directamente en el SERVIDOR WEB del comercio y que permite de forma manual hacer transacciones por parte del titular del comercio. Esta opción es distinta del TPV virtual y no requiere tener conocimientos de programación. Su funcionamiento es el siguiente. La persona que quiera realizar la compra debe facilitar el número de tarjeta al comercio. El comercio entrará en una dirección de internet en la cual deberá identificarse como usuarios del comercio. Una vez dentro introducirá los datos proporcionados por su cliente y la operación será realizada. En caso de ser esta la utilidad deseada debe ponerse en contacto con su entidad para que le den más información al respecto.
Características más importantes: Las características más importantes, la versión 5.0 del TPV virtual permite: Uso protocolo SSL.- El CLIENTE sólo necesita disponer de un navegador WEB que soporte SSL 3.0 con claves de cifrado de 128 bits (prácticamente todas las versiones actuales de navegadores existentes en el mercado cumplen este requisito) y el COMERCIO sólo requiere estar creado y autorizado en las tablas del TPV virtual de CECA. Esta característica ya estaba presente en la versión anterior del TPV virtual. Esta solución garantiza: Secreto en la comunicación entre el CLIENTE/COMERCIO y el TPV virtual, puesto que todo el diálogo es SSL 3.0 con claves de cifrado de 128 bits (la versión SSL 2.0 no será soportada). Además, desde la versión 2.0, se añadió la funcionalidad de que los datos de la tarjeta de crédito/débito (PAN y Caducidad) puedan ser requeridos opcionalmente desde una página HTML presentada directamente por el TPV virtual, en lugar de por el COMERCIO, con lo que se le garantiza al CLIENTE por un lado que estos datos viajan siempre adecuadamente cifrados por la RED y por otro que nunca se le facilitan al COMERCIO.
3
Autentificación del COMERCIO e Integridad de los datos enviados entre el CLIENTE/COMERCIO y el TPV virtual. Comunicaciones Firmadas Todas las comunicaciones hacia el TPV virtual van protegidas por una firma electrónica que es calculada e insertada por el COMERCIO en base a sus propios datos (MerchantID, AcquirerBIN y TerminalID) y a los datos de la operación (Número de operación, Importe, Tipo de Moneda, Exponente). La firma electrónica es recalculada por el TPV virtual y comparada con la firma electrónica recibida antes de proceder a aceptar cualquier pago. De esta forma se evita que un tercero pueda manipular cualquier dato entre el envío de los datos desde el comercio hasta el TPV virtual. El mismo mecanismo se sigue en la comunicación desde el TPV Virtual hacia el COMERCIO, en caso de que la haya. Pago 3D-Secure (Verified by Visa / Mastercard SecureCode.- Una Compra
securizada en Internet consiste básicamente en la Autentificación del titular de la tarjeta. El CLIENTE, para ser autenticado por su entidad emisora debe tener acceso a alguna herramienta de identificación. El COMERCIO sólo requiere estar creado y autorizado en las tablas del TPV virtual de CECA y haber sido declarado como Securizado o Mixto. La transacción se procesará independientemente de si el CLIENTE dispone o no de una herramienta de autenticación. Esta solución garantiza: Secreto en la comunicación entre el CLIENTE/COMERCIO y el TPV virtual, puesto que todo el diálogo es SSL 3.0 con claves de cifrado de 128 bits. Securización del COMERCIO e Integridad de los datos enviados entre el CLIENTE/COMERCIO y el TPV virtual. Autenticación del Cliente. Las operaciones realizadas por este método tratan de garantizar el pago al comercio en las operaciones en que los titulares niegan su participación en las mismas (repudio). . El emisor de la tarjeta trata de autentificar al titular. Garantía de pago. En general para este tipo de operaciones, el COMERCIO tendrá garantía de pago ante posibles repudios del titular. . Para mas detalle sobre la garantía de pago, revisar la versión actualizada del “REGLAMENTO DEL TERMINAL PUNTO DE VENTA VIRTUAL DE CONFEDERACIÓN ESPAÑOLA DE CAJAS DE AHORROS” Desde CECA (Confederación Española de Cajas de Ahorro) impulsamos el estándar internacional de Comercio Electrónico Seguro desarrollado por Visa y MasterCard, basado en la securización de la identidad del comercio y autenticación del titular de la tarjeta.. El mecanismo de autenticación lo marcarán los distintos emisores pudiendo ser totalmente diferentes en función de la entidad. Cuando el cliente aprueba la operación a través de una identificación positiva el comercio recibe entonces confirmación del pago. Es en ese momento cuando la compra está efectuada y pagada con seguridad para el comercio y para el titular. Una compra efectuada a través de este sistema tendrá en general garantía de pago para el comercio ante posibles repudios del titular. De está forma se trata de eliminar uno de los mayores problemas de las operaciones actuales en Internet que denominaríamos como compras estándar, donde al no estar identificado el cliente, este puede a posteriori anular la operación alegando desconocimiento o participación en la operación. En ciertos casos puntuales, y ante la certeza de que un comercio escudado en la garantía de pago ha iniciado una actividad fraudulenta (o ha relajado sus mecanismos de control del fraude permitiendo a un tercero una actividad fraudulenta en el mismo), los sistemas internacionales o nacionales pueden acordar su pérdida de la garantía de pago durante un periodo determinado de tiempo, así como imponerle otras penalizaciones.
4
2.- POR DÓNDE EMPEZAR: A continuación se muestran una serie de pasos a realizar para implementar un TPV en la WEB del comercio. Estos pasos son orientativos, y cada comercio puede adaptarlos según su forma de trabajar. 1. Cómo se decía en el punto primero de este manual, la persona que vaya a implementar el TPV deberá tener los conocimientos de programación necesarios. 2. El comercio deberá tener un espacio web donde albergar la tienda, ya sea a través de sus propios recursos o contratando un hosting con alguna empresa que permita la instalación de TPVs. En el apartado 5 Rutina del cálculo de la firma - Formas habituales de Uso y requisito del hosting se describen los requisitos que debe tener. 3. Tener instalada alguna aplicación de comercio electrónico (página web de la tienda) que permita al cliente poder seleccionar los productos que desea comprar 4. Conocer el tipo de comercio que ha contratado y su funcionamiento. (Ver apartados 3 Tipo de comercios y 4 Escenarios de pagos)
5. Una vez que el cliente ha seleccionado los productos y va a proceder al pago, se debe calcular una firma a partir de una serie de campos. Para calcular dicha firma el comercio debe utilizar la clave de cifrado recibida. Una vez calculada la firma desde el script (php, perl, etc) ésta será enviada a CECA junto con e resto de campos necesarios, bien al entorno de pruebas bien al entorno de producción (Ver Apartado 6.2- Programación a realizar en el servidor del comercio - Ejemplos de formulario) 6. En esta nueva versión ya no es necesario personalizar las páginas de pago como en versiones anteriores, ya que el propio TPV las incorpora de serie cumpliendo con una serie de requisitos explicados en el apartado 7 del manual. 7. Por último y si de desea tener confirmación en la WEB del comercio de las operaciones realizadas se procederá a configurar la comunicación on-line. Para ello el comercio tendrá que realizar el desarrollo de un proceso con esa función e indicar a CECA su URL. (Ver apartado 8 Comunicación on-line)
5
3.- TIPOS DE COMERCIOS: Existen varios tipos de comercios definidos dentro de la solución TPV de las Cajas de Ahorros. El desarrollo WEB para un comercio es el mismo para todos los casos, sólo depende del acuerdo que se tenga con la entidad. El cambio de un tipo a otro es transparente para el comercio, pero antes se debe tener claro lo que significa cada tipo. Ahora mismo hay definidos 3 tipos de Comercios.
Estándar/Inseguro: No se pide ninguna autentificación del cliente, solo se comprueba que la tarjeta tenga saldo y en algunos casos el CVV2/CVC2. Es importante destacar que No existe garantía de pago para el comercio, es decir, un cliente puede ir a su oficina varios meses después de realizar una operación y reclamar el importe alegando que desconoce el motivo del cargo. El banco retrocederá la operación y después debe ser el comercio quien inicie las acciones legales que considere oportunas contra el cliente para demostrar que el cargo es valido, pero por defecto, la entidad retrocede las operaciones. Sin duda alguna este tipo de comercio es el que más operaciones puede procesar, sin embargo debido al alto numero de incidencias tiende a desaparecer salvo en sectores que tienen un fraude bajo, como venta de entradas, donde posteriormente se exige la presentación de la tarjeta. La mayoría de entidades no concede altas para este tipo de comercios.
Seguro: Solo se admiten operaciones donde el cliente se ha autenticado correctamente contra su entidad o bien la entidad se hace responsable del posible uso fraudulento de sus tarjetas en caso de no autenticar al titular y autorizar la operación. En principio, todas las operaciones que se admiten con este sistema tienen garantía de pago. Por tanto la ventaja es clara, sin embargo actualmente no todas las tarjetas están activas para funcionar en este sistema y son muchos los clientes que por desconocimiento o simplemente porque no quieren introducir sus datos de Banca Electrónica, no se autentican y por tanto la operación no finaliza correctamente. En ciertos casos puntuales, y ante la certeza de que un comercio escudado en la garantía de pago ha iniciado una actividad fraudulenta (o ha relajado sus mecanismos de control del fraude permitiendo a un tercero una actividad fraudulenta en el mismo), los sistemas internacionales o nacionales pueden acordar su pérdida de la garantía de pago durante un periodo determinado de tiempo, así como imponerle otras penalizaciones.
Mixto: Es una mezcla de lo anterior. En primer lugar las operaciones se intentan hacer como seguras. Si la operación no puede ser lanzada por este modo, se lanza como una operación normal, siempre y cuando el importe sea menor al definido por el comercio (Limite a securizar), que puede consultar y modificar desde la administración del comercio. En este caso en las operaciones seguras el comercio tiene garantía de pago y en las no seguras el responsable es el propio comercio. Que el comercio sea mixto no quiere decir que las operaciones con importes inferiores a importe indicado se procesen de modo inseguro. El limite securizado no funciona de ese modo. Si una tarjeta admite autenticación, el proceso de autenticación se inicia independientemente del importe de la operación. El TPV si el comercio es seguro o mixto interroga a Visa/MasterCard para saber si una tarjeta admite autenticación. Si la tarjeta admite auntenticación en todos los casos (no importa el importe) se presenta la pagina de autenticación de la entidad que corresponda. Una vez se presenta la pagina del banco para iniciar el proceso de autenticación hay dos
6
opciones. -. El banco que corresponda no permite continuar sin autentificarte -. El banco que corresponda permite continuar temporalmente sin autentificarte o te pide el CVC2 o un dato de seguridad inferior para que temporalmente puedas comprar en comercio seguro El TPV no influye para nada en este proceso, es decisión única del banco emisor que permita a sus clientes continuar o no continuar, es decir, comprar o no comprar en comercio seguro sin autenticarse.
7
4.- ESCENARIOS DE PAGOS: Pago en comercio electrónico Estándar/no seguro: El esquema básico de funcionamiento es el siguiente:
1
Comercio
Cliente
7 10
4
3
8
2
TPV Virtual
5
6
9
Pasarela SET/SEP
8
1. Una vez que el cliente ha finalizado de confeccionar el pedido, y solicita pagar mediante tarjeta de crédito/débito, el comercio le presenta la página de pago en un formulario HTML en el que no se requieren los datos de la tarjeta de crédito/débito. 2. Al pulsar el cliente el botón Aceptar, la información es enviada al TPV virtual instalado en CECA. 3. Si los datos recibidos son correctos, el TPV virtual le presenta al cliente una página HTML con un formulario que contiene los mismos campos ocultos recibidos en el punto 2, en el que se requieren los datos de la tarjeta de crédito/débito. Esta página podrá ser personalizada por Comercio ó Caja Merchant. 4. El cliente rellena el formulario y al pulsar el botón Aceptar, la información es enviada al TPV virtual instalado en CECA. 5. Si los datos recibidos son correctos, el TPV virtual solicita el pago a la pasarela SET/SEP. 6. La pasarela SET/SEP devuelve el resultado de la operación al TPV virtual. 7. Si la operación se ha efectuado correctamente, el TPV virtual informa al comercio. 8. El Comercio comprueba y registra la operación y comunica nuevamente el resultado al TPV virtual. 9. Si en el paso anterior el TPV virtual no consigue comunicar la operación al comercio o éste detecta algún problema, el TPV virtual solicita a la pasarela SET/SEP que anule la operación. 10. El TPV virtual informa finalmente al cliente del resultado de la operación.
NOTA: Como se verá más adelante, los pasos 7, 8 y 9 son opcionales por comercio. Este caso se corresponde a un caso con comunicación on-line y respuesta requerida activada. En este caso el comercio nunca conocerá el número de tarjeta empleado en la transacción ya que este dato no se envía ni en los procesos de comunicación on line ni aparece reflejado en la consulta de operaciones. Existe la posibilidad de que los datos de la tarjeta sean solicitados por el comercio. En este caso el comercio debe justificar la necesidad de operar de esta forma y tener la aprobación por parte de la entidad bancaria. Además el comercio deberá auditar los procesos de seguridad necesarios definidos por VISA y Mastercard que permita custodiar los datos de la tarjeta de forma totalmente segura. El comercio podrá recibir una auditoria para verificar que dichos procesos de seguridad se están realizando.
9
Pago en comercio electrónico Seguro (3D-Secure) El esquema básico de funcionamiento es el siguiente:
1
Comercio Cliente
5
4
3
2 7 13
14
6 16
9
Identificación Titular
TPV Virtual
10 12 7
15
8
11
BANK Server Pasarela SET/SEP
10
Siendo: 1. Una vez que el cliente ha finalizado de confeccionar el pedido en una tienda que presente los logotipos "Verified by Visa" o "MasterCard© Secure Code", seleccionados los productos y solicitado el pago mediante tarjeta de crédito / débito, el comercio le presenta la página de pago en un formulario HTML en el que no se requieren los datos de la tarjeta de crédito / débito. 2. Al pulsar el cliente el botón Aceptar, la información es enviada al TPV virtual instalado en CECA. 3. Si los datos recibidos son correctos, el TPV virtual le presenta al cliente una página HTML con un formulario que contiene los mismos campos ocultos recibidos en el punto 2, en el que se requieren los datos de la tarjeta de crédito/débito. Esta página podrá ser personalizada por Comercio ó Caja Merchant. 4. El cliente rellena el formulario y al pulsar el botón Aceptar, la información es enviada al TPV virtual instalado en CECA. 5. El sistema detecta que su tarjeta está activada en Comercio Electrónico Seguro, e inicia la autenticación de su titular. 6. Esta autenticación del titular se realizará a través de una pequeña pantalla que en ese momento se abre. Esta securización se podrá realizar por varios caminos, a través de Vini, por Teléfono móvil, contra banca electrónica, etc.. Este mecanismo es propio del emisor de la tarjeta y por tanto difiere bastante en función de quien es el emisor de la tarjeta. 7. El cliente debe identificarse mediante el mecanismo facilitado por su entidad y por tanto autorizar la operación. 8. Si se confirma la identidad del usuario, el emisor procede a autorizar la operación. La ventana emergente se cerrará y continuará la operación adelante. 9. El emisor autoriza la operación emitiendo una firma única para esta operación, envía la operación al TPV. 10. El TPV acepta la petición, comprueba datos e identifica la operación como securizada y lo remite al emisor. 11. Tras recibir el mensaje de petición de autorización, el emisor validará que el AAV de la petición de autorización es igual al generado originalmente y determinará si ese AAV fue usado anteriormente. De ser así, se deniega la operación. 12. La pasarela SET/SEP devuelve el resultado de la operación al TPV virtual. 13. Si la operación se ha efectuado correctamente, el TPV virtual informa al comercio. 14. El Comercio comprueba y registra la operación y comunica nuevamente el resultado al TPV virtual. 15. Si en el paso anterior el TPV virtual no consigue comunicar la operación al Comercio o éste detecta algún problema, el TPV virtual solicita a la Pasarela SET/SEP que anule la operación. 16. El TPV virtual informa finalmente al cliente del resultado de la operación.
NOTA: Como se verá más adelante, los pasos 13,14 y 15 son opcionales por comercio. Este caso se corresponde a un caso con comunicación on line y respuesta requerida activada. En este caso el comercio nunca conocerá el número de tarjeta empleado en la transacción ya que este dato no se envía ni en los procesos de comunicación on line ni aparece reflejado en la consulta de operaciones. Existe la posibilidad de que los datos de la tarjeta sean solicitados por el comercio. En este caso el comercio debe justificar la necesidad de operar de esta forma y tener la aprobación por parte de la entidad bancaria. Además el comercio deberá auditar los procesos de seguridad necesarios definidos por VISA y Mastercard que permita custodiar los datos de la tarjeta de forma totalmente segura. El comercio podrá recibir una auditoria para verificar que dichos procesos de seguridad se están realizando.
11
5.- CÁLCULO DE LA FIRMA Uno de los parámetros que recibe TPV en su llamada es el parámetro firma. Dicho parámetro es utilizado para autenticar la llamada realizada y comprobar que su contenido no ha sido alterado por terceros. El algoritmo utilizado para calcular la Firma es: Secure Hashing Standard FIPS PUB 180-1 [http://www.itl.nist.gov/fipspubs/fip180-1.htm], comúnmente conocido como SHA-1. El resultado produce una salida de 160 bits (20 bytes) que se debe codificar en HEXADECIMAL con letras minúsculas. La mayoría de los algoritmos suelen devolver 5 bloques de 4 bytes cada uno, para posteriormente convertirlo en una cadena a enviar en un formulario HTML. Dicha cadena se debe convertir a hexadecimal y rellenar a ceros por la izquierda en caso necesario. La mayoria de los lenguajes de programación tienen una segunda función que realiza esta operacióin. Para aclarar un poco lo explicado en el párrafo anterior vamos a utilizar el siguiente ejemplo: Cadena: SHA1("11439044111950028000055405200000003221__0.67530300126148883300000000000197 82120035304709122214340106007000") Longitud: 106 Resultado: 62753a72 498191fd 09175074 7b8750bc 6cb06e8f En el tercer bloque, algunos algoritmos pueden devolver 9175074 , es necesario que sean 8 caracteres, por tanto será 09175074 . SHA1("") = da39a3ee5e6b4b0d3255bfef95601890afd80709 SHA1("El coche amarillo") = 968be676ad7988e8d911fce686da3fececbb22eb En internet existen varios sirios online para realizar pruebas de cifrado por SHA1 que puede servirle al comercio como referencia. Una vez explicado a grandes rasgos el funcionamiento del algoritmo SHA1 pasamos a explicar la forma de calcular la firma para su implementación en el comercio. El comercio debe enviar dos parámetros con el siguiente formato (En el punto siguiente del manual se explica detalladamente todos los parámetros que son necesarios enviar)
y la firma calculada con SHA1 concatenando los parámetros Clave_encriptacion+MerchantID+AcquirerBIN+TerminalID+Num_operacion+Importe+Tipo Moneda+Exponente+Referencia+Cifrado+URL_OK+URL_NOK Ejemplo: Clave encriptacion: 99888888 (no viaja en el formulario) MerchantID: 111950028 AcquirerBIN: 0000554052 TerminalID: 00000003 Num_operacion: 123
12
Importe: 500 TipoMoneda: 978 Exponente: 2 Referencia: URL_OK: http://www.ceca.es URL_NOK: http://www.ceca.es -->Cadena_sha1: 998888881119500280000554052000000031235009782SHA1http://www.ceca.eshttp://www.ceca.e s -->Longitud:[85] -->Firma_calculada: 15ba153908476895d9edd75ff23b207707d2c885
Para la comunicación on line, el proceso es el mismo. La firma enviada por el TPV es con los campos actuales Clave_encriptacion+MerchantID+AcquirerBIN+TerminalID+Num_operacion+Importe+Tipo Moneda+Exponente+Referencia
En el caso de que el comercio decida hacer la programación para poder realizar anulaciones desde su página web, la cadena de la firma con sha-1 en las anulaciones es como la de la comunicación on line expuesta anteriormente.
13
6.- PROGRAMACIÓN A REALIZAR EN EL SERVIDOR DE COMERCIO Como se dijo en la introducción de este manual, la implantación requiere de unos conocimientos de programación por parte del comercio y los cuales se detallan a continuación Una vez que el cliente conectado al Servidor WEB del Comercio finalice de elaborar la lista de la compra y solicite efectuar el pago mediante tarjeta de crédito/débito, dicho servidor deberá presentarle una página HTML que contendrá obligatoriamente un formulario con los siguientes campos: Nombre
Longitud
Descripción
MerchantID
Requerido/ Opcional Requerido
9
AcquirerBIN
Requerido
10
TerminalID
Requerido
8
Num_operacion
Requerido
50
Importe
Requerido
10
TipoMoneda
Requerido
3
Exponente URL_OK
Requerido Requerido
1 500
URL_NOK
Requerido
500
Firma
Requerido
256
Idioma Pago_soportado Pago_elegido
Opcional Requerido Opcional
1 SSL SSL
Descripcion
Opcional
1000
PAN
Opcional
19
Caducidad
Opcional
6
Identifica al comercio. Facilitado por la caja en el proceso de alta Identifica la caja. Facilitado por la caja en el proceso de alta. Identificativo del Terminal. Actualmente para todos los TPV virtuales es siempre 00000003 a no ser que tenga más de un TPV contratado. En ese caso el código de Terminal será 00000003, 00000004,… Identifica para el comercio la operación, nº de pedido, factura, albaran, etc.… Puede ser alfanumérico pero están prohibidos los caracteres extraños típicos como ¿,?,%,&,*,etc. Importe de la operación sin formatear. Siempre será un número entero donde los dos últimos dígitos serán los céntimos de Euro. Es el código ISO-4217 correspondiente a la moneda en la que se efectúa el pago. Contendrá el valor 978 para Euros. * Ver apéndice para códigos otras moneda Actualmente siempre será 2 URL completa (http://…). Es la URL determinada por el comercio a la que CECA devolverá el control en el caso de que la operación finalice correctamente. URL completa (http://…) Es la URL determinada por el comercio a la que CECA devolverá el control en el caso de que la operación no pueda realizarse por algún motivo. Es una cadena de caracteres calculada mediante una rutina proporcionada por CECA al comercio en una librería. En principio, esta librería estará disponible para entornos UNIX (SOLARIS, HP-UX, AIX y LINUX) y WINDOWS-NT/2000. En esta versión también se ha portado esta rutina a JAVA, por lo cual queda resuelta la portabilidad a todas las máquinas en las que esté instalada la Máquina Virtual JAVA. Código alfanumérico de idiomas SSL Dependiendo de quien solicite los datos de la tarjeta. Si los solicita el comercio será SSL. Si los solicita el TPV será vacío o no viajará. Campo reservado para mostrar información extra en la página de pago. Nº de tarjeta del cliente. Solamente necesario si el cliente solicita estos datos. Fecha de Caducidad. Formato AAAAMM. Solamente necesario si el cliente solicita estos datos.
14
CVV2
Opcional
Referencia
Opcional
30
CVC2 de la tarjeta. Solamente necesario si el cliente solicita estos datos. En las compras será "", en las anulaciones el valor asignado en su momento a la operación de compra.
Cualquier otro parámetro enviado al TPV virtual no será tenido en cuenta y se perderá en el proceso.
El campo ACTION del formulario apuntará a una URL de un Servidor WEB de CECA correspondiente al CGI que tratará tanto los datos de la operación rellenos por el Servidor WEB del Comercio como los posibles datos de la tarjeta rellenos por el cliente. La dirección se encuentra en el punto 6.3 Direcciones que veremos más adelante. El campo número de operación no debe volverse a repetir hasta transcurridos 24 horas, independientemente de si la operación ha sido o no procesada con éxito. En el caso de repetirse aparecerá un error de “operación incorrecta”
6.1.- Compatibilidad con versiones anteriores
a) Pago_soportado.- Este campo, añadido en la versión 2.0 del TPV Virtual es opcional con el fin de poder mantener la compatibilidad con la versión anterior. Para las nuevas implementaciones su valor será obligatorio y deberá contener el valor SSL.
b) PAN.- Campo opcional de entrada de 19 caracteres como máximo. Es el Número de la tarjeta introducido por el cliente. Con objeto de mantener la compatibilidad con la versión anterior del TPV virtual, este campo sólo deberá ir relleno si el campo Pago_soportado y Pago_elegido están informados con el valor SSL, puesto que de lo contrario, será el propio TPV virtual quien deba solicitar los datos de la tarjeta al cliente, tal y como ya se ha descrito en un punto anterior.
c) Caducidad.- Campo opcional de entrada de 6 caracteres. Es la fecha de caducidad de la tarjeta en formato AAAAMM introducido por el cliente. Con objeto de mantener la compatibilidad con la versión anterior del TPV virtual, este campo sólo deberá ir relleno si el campo Pago_soportado y Pago_elegido están informados con el valor SSL, puesto que de lo contrario, será el propio TPV virtual quien solicite los datos de la
tarjeta al cliente, tal y como ya se ha descrito anteriormente.
d) Idioma. Los idiomas soportados actualmente son: 1.- Español 6.- Inglés
2.- Catalán 7.- Francés
3.- Euskera 8.- Alemán
4.- Gallego 9.- Portugués
5.- Valenciano 10.- Italiano
e) Descripción.- Campo opcional, variable y oculto. Es la descripción del pedido asignada por el comercio que podrá visualizarse en la pagina de pago o bien en algún tipo de monedero compatible con está especificación.
15
6.2 Ejemplos de formularios
Ejemplo de llamada en la que los datos de tarjeta son solicitados por el TPV
Página de pago Importante: Si hace un copiado de este código a través de la opción copy-paste asegúrese de que el código destino es correcto. En algunos casos se ha detectado que al copiar el código las “ (comillas dobles) se han sustituido por ‘’ (2 comillas simples)
Obviamente, la aplicación deberá sustituir los literales de los campos VALUE que comienzan y terminan con ## por los valores adecuados.
16
Ejemplo de llamada en la que los datos de tarjeta son solicitados por el comercio
Página de pago Tarjeta: Caducidad: CVV2/CVC2: Importante: Si hace un copiado de este código a través de la opción copy-paste asegúrese de que el código destino es correcto. En algunos casos se ha detectado que al copiar el código las “ (comillas dobles) se han sustituido por ‘’ (2 comillas simples)
Obviamente, la aplicación deberá sustituir los literales de los campos VALUE que comienzan y terminan con ## por los valores adecuados. Es decir además de los campos habituales en este caso deberá de enviar los siguientes campos: PAN: Número entero sin espacios en blanco ni caracteres extraños. Caducidad: Estrictamente en el formato AAAAMM. CVV2: Tres dígitos numérico (más información en apéndice) Pago_soportado=SSL Pago_elegido=SSL
17
Importante: Esta forma de funcionamiento debe contar con la aprobación por parte de la entidad bancaria, por defecto no está permitida. El comercio debe justificar la necesidad de esta forma de operar así como auditar los procesos de seguridad necesarios para solicitar datos bancarios desde su servidor.
6.3 Direcciones de llamada Conviene también citar en este punto, que existen dos entornos de TPV virtual instalados en CECA, siendo sus URLs correspondientes:
https://pgw.ceca.es/cgi-bin/tpv
ENTORNO DE PRODUCCION
http://tpv.ceca.es:8000/cgi-bin/tpv
ENTORNO DE DESARROLLO
Estos serán los únicos valores válidos en el campo ACTION de los formularios descritos anteriormente.
18
7.- PÁGINAS DE PAGO Por cada comercio, el TPV virtual maneja un juego de páginas compuesto por: MerchantID_ssl.html
MerchantID_ok.html
MerchantID_error_atras.html MerchantID_error_maximo.html
Pagina donde se solicita los datos de Tarjeta y fecha de caducidad. No se presenta si estos datos ya son enviados por el comercio. Pagina de resumen de la operación si está finaliza correctamente. Se continúa a la dirección indicada por el comercio en el campo URL_OK. Pagina de error, permite reintentar la operación. Pagina de error. Informa del error y se continúa a la dirección indicada en el campo URL_NOK indicada por el comercio.
La mayoría de las entidades dispone de un juego de páginas que todos sus comercios deben utilizar, algunas incorporan un logo del comercio y no permiten utilizar paginas propias. Antes de iniciar cualquier desarrollo es importante que contacte con su entidad o con
[email protected] para saber la política de su entidad al respecto. En el caso donde se permita la personalización de las páginas se enviará al comercio unas plantillas sobre las que añadir el diseño grafico En el caso de que un comercio necesite utilizar unas páginas distintas de las de por defecto deberá ponerse en contacto con
[email protected] donde se le dará las instrucciones necesarias para su personalización.
7.1.- Características de las páginas de pago propias del TPV En el caso de que su entidad utilice las páginas de pago propias del TPV, estas poseen las siguientes características. Páginas ya preparadas para multi-idioma en la que se incluyen Castellano, Catalán, Euskera, Gallego, Valenciano, Inglés, Francés, Alemán, Portugués, Italiano. Inclusión del logo de su entidad. Logo de AMEX (American Express) dinámico dependiendo de si el comercio acepta o no este tipo de tarjeta. Logos Visa y MC de comercio seguro dependiendo del tipo de comercio. Alta automática de estas páginas a los comercios sin necesidad de solicitarlas por correo. Posibilidad de impresión de la boleta al terminar la compra Páginas testeadas en los navegadores existentes en el mercado. Actualizaciones transparentes para todos los comercios que las utilicen con el fin de incluir las medidas de seguridad necesarias y de usabilidad que garanticen una compra segura.
19
8.- COMUNICACIÓN ON-LINE La comunicación on-line es utilizada por los comercios que necesita que las operaciones de COMPRA realizadas por sus clientes le sean comunicadas en el momento de producirse. Consiste en la creación de un proceso por parte del comercio al cual el TPV invocará cuando se haya tenido la aceptación de la operación por parte de la entidad emisora de la tarjeta del cliente. Dicha llamada podrá ser realizada por HTTP o HTTPS y se añadirá los siguientes campos para que el comercio pueda identificar la operación: Longitud
Descripción
MerchantID AcquirerBIN TerminalID
Nombre
9 10 8
Num_operacion
50
Importe
10
TipoMoneda
3
Exponente Referencia
1 30
Identifica al comercio. Facilitado por la caja en el proceso de alta Identifica la caja. Facilitado por la caja en el proceso de alta. Identificativo del Terminal. Actualmente para todos los TPV virtuales es siempre 00000003. Identifica para el comercio la operación, nº de pedido, factura, albarán, etc.… Puede ser alfanumérico pero están prohibidos los caracteres extraños típicos como ¿,?,%,&,*,etc.… Importe de la operación sin formatear. Siempre será una número entero donde los dos últimos dígitos serán los céntimos de Euro. Es el código ISO-4217 correspondiente a la moneda en la que se efectúa el pago. Contendrá el valor 724 para Pesetas y 978 para Euros. Actualmente solo se permiten pagos en Euros, luego el valor será 978. Actualmente siempre será 2
Firma
256
Num_aut Idioma Pais Descripcion
6 2 3 200
Referencia.- Es el único valor devuelto por la Pasarela SET/SEP. Este dato es imprescindible para realizar cualquier tipo de reclamación y/o anulación de la compra. Es una cadena de caracteres calculada mediante una rutina escrita en “C” proporcionada por CECA al comercio en una librería. En principio, esta librería estará disponible para entornos UNIX (SOLARIS, HP-UX, AIX y LINUX) y WINDOWS-NT/2000. En esta versión también se ha portado esta rutina a JAVA, por lo cual queda resuelta la portabilidad a todas las máquinas en las que esté instalada la Máquina Virtual JAVA. Valor asignado por la entidad emisora a la hora de autorizar una operación. Idioma de la operación Código ISO del país de la tarjeta que ha realizado la operación Los 200 primeros caracteres de la descripción
La funcionalidad de este proceso será la que determine el comercio, pero principalmente consistirá en actualizar sus bases de datos internas (situación del pedido). La URL a la que se envían los datos puede ser cualquier lenguaje de programación que pueda capturar los datos enviados por un formulario HTML por método POST. ASP, PHP, .net, perl, etc.….
IMPORTANTE: Si se realiza una compra en la web del comercio y en el mismo navegador web, compartiendo cookies, se encuentra la Web de administración abierta o ha estado abierta, no se produce el proceso de comunicación on-line aunque la operación se realiza de forma correcta. Debe reiniciar el navegador WEB o abrir sesiones distintas de navegación.
20
Comunicación online con respuesta requerida: En el caso que nos ocupa, en el que el comercio solicite una comunicación ON-LINE de las operaciones de compra realizadas por sus clientes, se contemplan además dos posibilidades: No se requiere una respuesta del comercio. En este caso, una vez realizado el pago, el TPV virtual de CECA intentará comunicar la operación al comercio, pero dará por realizada correctamente la operación aunque dicha comunicación no sea posible. Es más, ni siquiera esperará recibir una respuesta desde el comercio. Se requiere una respuesta del comercio. En este caso, si una vez realizado el pago, el programa no consigue comunicar la operación al comercio ó detecta a partir de la respuesta recibida que algo no ha ido bien, anulará la operación y la dará como errónea al cliente. Para que el programa sea capaz de discernir a partir de la respuesta recibida desde el Comercio si todo ha funcionado correctamente ó si se ha producido algún error, es necesario que en la respuesta generada por el CGI del comercio aparezca el texto $*$OKY$*$ sólo cuando todo vaya bien, de modo similar a como figura en el siguiente ejemplo:
Respuesta correcta a la comunicación ON-LINE $*$OKY$*$
8.1.- Ver y modificar la configuración online actual de su comercio Desde la Web de Administración pulsamos en el apartado Configuración y en los datos generales del comercio se puede visualizar la configuración actual.
21
Esquema del proceso Sin comunicación on line Y sin respuesta requerida
Operación Correcta
Con comunicación on line y sin respuesta requerida
Operación Correcta
Con comunicación on line y respuesta requerida
Operación Correcta
Se envía formulario a la dirección especificada Se presenta la pagina OK
Se envía formulario a la dirección especificada Se captura la respuesta (25 sg)
Se va a la URL_OK Se presenta la pagina OK
Incluye el string OKY
No responde o no incluye el string OKY
Se presenta la pagina OK
Se presenta la pagina Error atrás con
Se va a la URL_OK Se va a la URL_OK
ERROR en la comunicación on line.
22
9.- CONSULTA ONLINE DE OPERACIONES REALIZADAS: Con el fin de que los Comercios puedan consultar y/o anular las operaciones efectuadas por sus clientes, CECA ha instalado en uno de sus servidores WEB seguros, una aplicación accesible desde cualquier navegador, que permite a los comercios realizar un seguimiento online de su actividad. Para mayor información sobre esta herramienta consultar el apartado “Consola de administración del comercio” de este manual.
23
10.- COMUNICACIÓN BATCH DE LAS OPERACIONES REALIZADAS Tanto si el Comercio utiliza ó no la facilidad de comunicación ON-LINE de las operaciones de compra realizada por sus clientes, tal y como se describió en el apartado compras en INTERNET, CECA podrá generar y enviar al Comercio al final de cada día, un fichero que contendrá el listado de las operaciones efectuadas durante el mismo. Por motivos de seguridad, este fichero irá cifrado. Para descifrarlo será necesario hacer uso de las herramientas proporcionadas por CECA al Comercio. Para el envío de este fichero, el Comercio podrá optar por uno de los siguientes sistemas: a) E-MAIL.- El Comercio deberá determinar la cuenta de correo. b) FTP.- En este caso el Comercio deberá especificar los siguientes datos: Nombre ó dirección IP en INTERNET del servidor de FTP. Usuario y contraseña de acceso. El fichero se depositará siempre en el directorio raíz del usuario proporcionado, con el nombre AAAAMMDD.TPV, correspondiendo AAAAMMDD al año, mes y día de la fecha de transmisión respectivamente. El formato del fichero consistirá en registros de longitud variable, separados unos de otros por los caracteres RETORNO DE CARRO (Valor hexadecimal 0x0d) y SALTO DE LINEA (Valor hexadecimal 0x0a) con el fin de que sean fácilmente editables en un PC. Dentro de cada registro, los campos irán separados unos de otros por el carácter “,” (coma). Cada registro constará de los siguientes campos: 1. 2. 3. 4. 5.
Tipo de operación. Puede tomar los valores C (compra) o D (devolución). Fecha. Fecha y hora en formato DD/MM/AAAA hh:mm:ss. Número de operación. Número de operación asignado por el comercio. Importe. Importe sin formatear. Referencia. Es la referencia asignada por la Pasarela SET/SEP a la operación y que en el caso de una Compra, es necesario conocer para poder efectuar reclamaciones y/o anulaciones posteriores. 6. Num_aut. Numero de autorización de la operación proporcionada por la entidad resolutora de la operación. Para solicitar este envío deberá comunicarlo a través del correo
[email protected] indicando su código de comercio y forma de envío, así como los datos necesarios especificados anteriormente
24
11.- ANULACIÓN DE OPERACIONES Con objeto de permitir a los Servidores de Comercio solicitar la anulación de operaciones de Compra desde el propio Servidor, es decir, sin necesidad de utilizar la Consola de administración del comercio, existe un CGI que permite realizar esta funcionalidad a partir de un formulario HTML generado por el Comercio. Los campos que debe contener este formulario son los siguientes: Longitud
Descripción
MerchantID AcquirerBIN TerminalID
Nombre
9 10 8
Num_operacion
50
Importe
10
Tipo_moneda
3
Exponente Referencia
1 30
Identifica al comercio. Facilitado por la caja en el proceso de alta Identifica la caja. Facilitado por la caja en el proceso de alta. Identificativo del Terminal. Actualmente siempre para todos los TPV virtuales es 00000003. Identifica para el comercio la operación, nº de pedido, factura, albarán, etc.… Puede ser alfanumérico pero están prohibidos los caracteres extraños típicos como ¿,?,%,&,*,etc.… Importe de la operación sin formatear. Siempre será un número entero donde los dos últimos dígitos serán los céntimos de Euro. Es el código ISO-4217 correspondiente a la moneda en la que se efectúa el pago. Contendrá el valor 724 para Pesetas y 978 para Euros. Actualmente solo se permiten pagos en Euros. Actualmente siempre será 2
Firma
256
Idioma
1
Pagina
50
Referencia.- Es el único valor devuelto por la Pasarela SET/SEP. Este dato es imprescindible para realizar cualquier tipo de reclamación y/o anulación de la compra. Es una cadena de caracteres calculada mediante una rutina “C” proporcionada por CECA al comercio en una librería. En principio, esta librería estará disponible para entornos UNIX (SOLARIS, HP-UX, AIX y LINUX) y WINDOWS-NT/2000. En esta versión también se ha portado esta rutina a JAVA, por lo cual queda resuelta la portabilidad a todas las máquinas en las que esté instalada la Máquina Virtual JAVA. Es un campo numérico con una longitud máxima de 1 carácter. En caso de ir informado, permite que el TPV Virtual gestione diferentes juegos de páginas correspondientes a diferentes Idiomas para un mismo Comercio (soporte de multi-idioma). Así mismo, los mensajes de error devueltos por el TPV Virtual ó por la Pasarela de Pagos SET/SEP, serán también traducidos al idioma correspondiente. Es un campo alfanumérico, y sólo debe utilizarse si se desea que las páginas HTML mostradas al cliente sean diferentes de las páginas por defecto utilizadas por el TPV Virtual.
Acerca del campo Página.- Campo opcional variable y oculto. Es un campo alfanumérico, y sólo debe utilizarse si se desea que las páginas HTML mostradas al cliente sean diferentes de las páginas por defecto utilizadas por el TPV Virtual. En caso de no ir relleno, las páginas HTML mostradas por el CGI, correspondientes al juego de páginas HTML por defecto del TPV Virtual, son: anulacion_ok.html anulacion_error_atrás.html
Anulación correcta Problemas en la anulación
si el campo Idioma no está relleno, ó anulacion-_ok.html anulacion-_error_atrás.html
Anulación correcta Problemas en la anulación
25
Si va relleno, las páginas HTML mostradas por el CGI son: _ok.html _error_atrás.html
Anulación correcta Problemas en la anulación
si el campo Idioma no está relleno, ó -_ok.html -_error_atrás.html
Anulación correcta Problemas en la anulación
Obviamente, en este caso las páginas HTML deben haber sido previamente proporcionadas por el Comercio.
El campo ACTION del formulario apuntará a la URL de un Servidor WEB de CECA correspondiente al CGI que tratará los datos del formulario, y que podrá ser una de las siguientes:
https://pgw.ceca.es/cgi-bin/tpvanular http://tpv.ceca.es:8000/cgi-bin/tpvanular
PRODUCCION DESARROLLO
En la página siguiente se muestra un ejemplo de cómo debería ser este formulario HTML: Página de anular operaciones Importante: Si hace un copiado de este código a través de la opción copy-paste asegúrese de que el código destino es correcto. En algunos casos se ha detectado que al copiar el código las “ (comillas dobles) se han sustituido por ‘’ (2 comillas simples)
26
Obviamente, la aplicación deberá sustituir los literales de los campos VALUE que comienzan y terminan con ## por los valores adecuados.
De modo similar a como ocurre con las operaciones de compra, el comercio puede requerir que las operaciones de ANULACION realizadas le sean comunicadas en el momento de producirse. En este caso, la comunicación se realizará mediante protocolo HTTP ó HTTPS, por lo que el Comercio deberá desarrollar e instalar un proceso, comunicando a CECA la URL (incluyendo protocolo) del mismo. Este CGI será invocado con los siguientes parámetros: Longitud
Descripción
MerchantID AcquirerBIN TerminalID
Nombre
9 9 8
Num_operación
50
Importe
10
Tipo_moneda
3
Exponente Referencia
1 30
Identifica al comercio. Facilitado por la caja en el proceso de alta Identifica la caja. Facilitado por la caja en el proceso de alta. Identificativo del Terminal. Actualmente para todos los TPV virtuales es siempre 00000003. Identifica para el comercio la operación, nº de pedido, factura, albarán, etc.… Puede ser alfanumérico pero están prohibidos los caracteres extraños típicos como ¿,?,%,&,*,etc.… Importe de la operación sin formatear. Siempre será un número entero donde los dos últimos dígitos serán los céntimos de Euro. Es el código ISO-4217 correspondiente a la moneda en la que se efectúa el pago. Contendrá el valor 724 para Pesetas y 978 para Euros. Actualmente solo se permiten pagos en Euros, luego el importe siempre será un número entero sin formatear y donde los dos últimos dígitos siempre son céntimos. Actualmente siempre será 2
Firma
256
Referencia.- Es el único valor devuelto por la Pasarela SET/SEP. Este dato es imprescindible para realizar cualquier tipo de reclamación y/o anulación de la compra. Es una cadena de caracteres calculada mediante una rutina “C” proporcionada por CECA al comercio en una librería. En principio, esta librería estará disponible para entornos UNIX (SOLARIS, HP-UX, AIX y LINUX) y WINDOWS-NT/2000. En esta versión también se ha portado esta rutina a JAVA, por lo cual queda resuelta la portabilidad a todas las máquinas en las que esté instalada la Máquina Virtual JAVA.
La funcionalidad de este proceso será la que determine el comercio, pero principalmente consistirá en actualizar sus bases de datos internas.
Anulación parcial desde WEB del Comercio. El comercio debe disponer de una autorización por parte de su Caja antes de utilizar esta opción. Una vez activada esta opción por parte de la caja, el comercio cuando entra en su Consola de administración del comercio y procede a la anulación de una operación observará la posibilidad de anular la operación o realizar anulación parcial. Consultar en este mismo manual el apartado correspondiente para tener más detalle. Anulaciones parciales a través de formulario Al igual que las anulaciones totales las anulaciones parciales pueden ser procesadas a partir de un formulario enviado por el comercio. Las condiciones son iguales a las expuestas anteriormente y el comportamiento será igual al comportamiento en las anulaciones totales. Direcciones: Pruebas: http://tpv.ceca.es:8000/cgi-bin/tpvanularparcialmente Real: https://pgw.ceca.es/cgi-bin/tpvanularparcialmente
27
12.- CONSOLA DE ADMINISTRACIÓN TPV VIRTUAL PARA COMERCIOS Desde este entorno de administración es posible tener acceso a los informes sobre operaciones del comercios, realizar búsqueda de operaciones, anulaciones y establecer distintos filtros de compra, modificación de parámetros, …
Acceso La dirección establecida para el acceso a la consola de administración del TPV virtual es: https://pgw.ceca.es/xxx El usuario y password de acceso son los mismos que para la anterior administración y en caso de no tenerla serán proporcionados en el correo de bienvenida recibido por el comercio.
Cambio de entorno Existen dos entornos en los que se está ejecutando el TPV Virtual y ambos son autónomos. Estos entornos son pruebas y producción. Desde la consola podremos cambiar a cada uno de ellos mediante el enlace cambiar a pruebas o a real que aparece en la parte superior de la pantalla. Para cada uno de ellos cambian los colores de la consola para que visualmente se pueda distinguir en cuál de ellos estamos.
Día a Día –Comparar fechas Esta opción nos permite comparar el importe y número de operaciones procesadas entre dos días. Por defecto, compara hoy con el mismo día de la semana anterior, pero ambas fechas son modificables. Si una de las fechas es el día actual, la comparación se limitará hasta la hora en curso. Se puede limitar las operaciones a comparar por tipo (compra, anulación) y por resultado (OK, NOK, filtrada). Una compara OK es aquella que ha sido procesada correctamente, NOK la que se ha intentado procesar pero ha sido denegado y filtrada es aquella que no se ha llegado a procesar por cumplir alguno de los filtros definidos por la caja y/o comercio. A la derecha de cada gráfico existen unos porcentajes que serán visibles en el caso de que no estemos filtrando por alguno de los parámetros antes mencionados y nos indicará el porcentaje de operaciones anuladas y el porcentaje de operaciones NOK con respecto al total. Además debajo de cada gráfico aparece un sumatorio con el número total de operaciones por día que estamos comparando.
28
Día a Día –Ver informes diarios Permite sacar un informe de las operaciones procesadas durante un periodo. En dicho informe se presenta el número total de operaciones -compras y devoluciones- con su importe correspondiente. El periodo de consulta está limitado a un máximo de 31 días. En el caso de que el comercio permita realizar operaciones por AMEX estas podrán ser excluídas del informe
Listado de operaciones Listado de las operaciones realizadas durante un periodo determinado. La aplicación nos permite hacer una búsqueda en base a unos parámetros básicos como son Fecha de inicio, finalización, tipo (compra, anulación), resultado (OK,NOK, filtrada) y canales (Internet, pago periódico, pago directo, email, tpv-blanco)
29
En el caso de que los parámetros anteriores no sean necesarios para localizar una operación podemos pinchar sobre el botón Más opciones y nos permitirá también buscar por un rango de importe, número de tarjeta, número de operación y número de autorización. En el caso del número de tarjeta este campo admite el carácter comodín % de tal manera que si queremos buscar todas las tarjetas que empiecen por 7854 pondremos en dicho campo el valor 7854%. El carácter comodín podemos ponerlo en cualquier parte del campo, es decir si conocemos los primeros dígitos de la tarjeta y los últimos podremos utilizar el valor 9999%99 y nos dará como resultado todas las tarjetas que comiencen por 9999 y que además terminen en 99. Por cada una de las operaciones que aparecen en el listado podremos consultar su detalle y proceder a su anulación.
Detalle de una operación Para cada una de las operaciones localizadas en el apartado anterior tenemos un enlace con la palabra más, lo que nos permite visualizar el detalle de una operación en cuestión. En el caso de que la operación esté anulada o la que intentamos visualizar sea una anulación, en la parte superior de esta pantalla aparece un enlace para poder navegar entre ellas.
30
Anulación de una operación Para anular una operación que ha sido realizada correctamente tendremos que buscarla en el listado de operaciones y una vez localizada tenemos dos alternativas. 1. Pinchar en el enlace más detalle y pulsar el botón anular operación 2. Pinchar en la X que aparece al final de la operación Por cualquiera de estos caminos se nos solicitará una confirmación antes de proceder a su anulación.
Anulación parcial de una operación Si su entidad lo permite un comercio puede realizar una anulación parcial de una operación. Para ello siguiendo los pasos descritos en el apartado de anulación de una operación nos aparecerá un nuevo apartado en el cual podremos indicar si queremos hacer una anulación total o parcial. Destacar que sólo se puede realizar una única anulación parcial por operación, es decir si una operación es de 100 euros y realizamos una anulación parcial de 75 euros, el resto no podrá ser anulado por este procedimiento, teniéndose que dirigir a su entidad para hacer el abono correspondiente al cliente. No todos los comercios disponen de esta opción, por lo que en caso de no aparecer deberá ponerse en contacto con su entidad.
Pagos periódicos Consulta de operaciones y pagos periódicos realizadas entre dos fechas determinadas. No todos los comercios disponen de esta opción, por lo que en caso de no aparecer deberá ponerse en contacto con su entidad. Una operación periódica es el conjunto de pagos que forma una operación. Existen 3 tipos de operaciones de este tipo:
Operación aplazada. Pago actual más uno en una fecha determinada. Operación a plazos. Pago actual más un número de pagos con un importe determinado. Operación 25/75. Pago actual del 25% del importe más uno en una fecha determinada del 75%.
31
Dentro de este apartado tenemos que distinguir entre dos conceptos: Operación: Es una operación fraccionada en varios pagos. Por ejemplo la suscripción anual a una revista con un pago mensual de 10 euros. La operación es de 120 euros Pago: Es cada uno de las pagos que forman una operación. En el ejemplo anterior tendremos un total de 12 pagos.
Operaciones de un pago periódico Una operación periódica es el conjunto de pagos que forma una operación. Desde esta opción podremos consultar todas las operaciones realizadas de este tipo. La aplicación nos permite hacer una búsqueda en base a unos parámetros básicos como son rango de fechas. En el caso de que los parámetros anteriores no sean necesarios para localizar una operación podemos pinchar sobre el botón Más opciones y nos permitirá también buscar por un rango de importe, número de tarjeta, número de pagos y referencia de la operación. Los posibles estados de una operación son: Activa. La operación tiene pagos pendientes de realizar Cancelada. La operación ha sido cancelada por el usuario. Finalizada. La operación ya no tiene pagos pendientes de realizar Para cada operación, la aplicación nos permite realizar alguna de las siguientes acciones: Acceder a los pagos de los que está compuesta, para ello pulsaremos sobre el icono que aparece en la columna de pagos Consultar los detalles de la operación. Pinchando el botón más que aparece por cada operación Anular la operación. Pinchando el icono de anular X que aparece al final de cada operación. En el caso de que la operación ya esté anulada, este icono no aparecerá
32
Pagos de un pago periódico Un pago periódico es una parte de una operación periódica. Desde esta opción podremos consultar todas las operaciones realizadas de este tipo. La aplicación nos permite hacer una búsqueda en base a unos parámetros básicos como son rango de fechas y estado. En el caso de que los parámetros anteriores no sean necesarios para localizar un pago podemos pinchar sobre el botón Más opciones y nos permitirá también buscar por un rango de importe, número de tarjeta, referencia de pago y referencia de la operación. Los posibles estados que puede tener un pago son los siguientes: Anulado. Pago que na sido anulado una vez se ha procesado con éxito Cancelado. Pago que ha sido cancelado antes de llegar a su fecha de pago. Cancelado con error. Pago cuyo estado era error y al procesarlo de nuevo ha vuelto a fallar. El original aparece con este estado y aparece un registro nuevo con el estado de error Cancelado por modificación con error. Pago que ha dado un error y ha sido modificado para volverse a procesar. El original aparece con este estado y aparece un registro nuevo como pendiente Cancelado por modificación. Pago que ha sido modificado antes de llegar a su fecha de pago. El original aparece con este estado y aparece un registro nuevo como pendiente En curso. Pago que se está realizando en este momento. Error. Pago que ha sido procesado y su resultado ha sido error. Pagado. Pago que ha sido procesado de forma correcta. Pendiente. Pago que está pendiente de procesar por no haber llegado la fecha de pago. Por cada pago que nos aparece en la consulta podremos realizas las siguientes acciones dependiendo de su estado Consultar los detalles del pago Anular Reprocesar la operación Modificar
33
Pagos directos Un pago directo es una operación que se genera íntegramente por el comercio desde la consola de Administración sin utilizar las páginas web del comercio. No todos los comercios disponen de esta opción, por lo que en caso de no aparecer deberá ponerse en contacto con su entidad. Esta opción solo tiene sentido si el cliente ha facilitado los datos de su tarjeta al comercio y el tipo de comercio es no seguro, ya que en caso contrario saltaría las pantallas de autenticación del cliente, siendo estos desconocidos por el comercio. En el caso de que el comercio no disponga de los datos de pago deberá utilizar el pago por email explicado más adelante.
34
Pagos por email Un pago por email es una operación que es dada de alta por el comercio y que se envía por email al cliente, para que la complete introduciendo los datos de su tarjeta. No todos los comercios disponen de esta opción, por lo que en caso de no aparecer deberá ponerse en contacto con su entidad.
Una vez que el comercio ha realizado la operación se enviará un email al cliente con las instrucciones necesarias para terminar la compra. Se podrá realizar un seguimiento de la misma a través de esta consola. Los posibles estados que puede tener una operación por email son los siguientes: Enviado. La operación ha sido enviada al cliente y está a la espera de su terminación. Completado OK. La operación ha sido enviada al cliente y éste ha introducido los datos de pago correspondiente siendo su resultado satisfactorio. Completado NOK. La operación ha sido enviada al cliente y éste ha introducido los datos de pago correspondiente siendo su resultado error. Cancelado. La operación ha sido enviada al cliente, pero el comercio ha decidido cancelarla antes de que el cliente haya intentado terminarla. En el caso de que el cliente ya haya terminado la operación esta no podrá ser cancelada. Para ello deberá dirigirse al listado de operaciones y anularla como se ha explicado en el punto anterior de este manual. Por cada uno de los pagos que aparece en la consulta de pagos por email, dependiendo del estado en el que se encuentra, se podrá realizar las siguientes acciones: Cancelar.
35
Configuración – Datos del comercio Visualiza y modifica la configuración del comercio. En la configuración se define el comportamiento del TPV a la hora de procesar una operación, realizada desde la página web del comercio. Esta pantalla está dividida en tres apartados: Datos del comercio. Son los datos con los que ha sido registrado el comercio. Estos datos no pueden ser modificados desde la consola Configuración del pago. Indica el comportamiento que va a tener el comercio a la hora de procesar un pago. Los parámetros que pueden ser modificados por el usuario son: o Comunicación online o Respuesta requerida o Url-online o Límite securizado Existe un apartado específico en este manual para cada uno de los parámetros anteriores en donde se explica con más detalle el significado de cada uno de ellos.
Otros datos del comercio. Se muestran otros tipos de datos relativos al comercio como son la fecha de alta, su estado,.. Configuración del servicio. Indica el estado en que se encuentran las distintas opciones que puede realizar un comercio dentro de su operatoria. Este estado no es modificable por el usuario y en caso de querer cambiar alguno de ellos debe poner en contacto con su Caja
Es recomendable estar completamente seguro a la hora de realizar alguna modificación sobre estos parámetros.
36
Configuración – Filtros de compra Un filtro es un control que se realiza antes de realizar una operación en el tpv. En el caso de que se cumpla alguno de ellos, la operación no será procesada y aparecerá en la consulta de operaciones como “filtrada”. No todos los comercios tienen esta opción disponible, por lo que en caso de no aparecer y estar interesado en ella deberá ponerse en contacto con su Caja para que se la habilite. Actualmente existen cuatro tipos de filtros: Límites por importe. Límites por origen. Nos permite filtrar las operaciones que se vayan a realizar en nuestro comercio desde una determinada dirección IP o desde un rango de ellas. Límites por BIN de la tarjeta. El BIN de la tarjeta define el tipo al que pertenece. Por ejemplo las tarjetas que comienzan por 999999 son del tipo A. Si queremos que las tarjetas de este tipo no operen en nuestro comercio podremos activar este filtro y cuando un cliente intente operar con ella, esta será filtrada por el TPV sin llegarse a procesar. Límites por PAN de la tarjeta. El PAN de la tarjeta define su numeración completa. Al igual que en el punto anterior podemos filtrar para que una determinada tarjeta o un rango de ellas no pueda operar en nuestro TPV.
Aunque los filtros estén definidos, estos no serán efectivos hasta que estén activados. Para ello existe al final de la página un botón que nos permite activarlos o desactivarlos según su estado actual Realizar con mucho cuidado cualquier modificación sobre alguno de estos parámetros.
37
Usuarios y perfiles Consulta y administra los usuarios que tienen acceso a la consola del TPV. La consola de administración del TPV-Virtual maneja tres tipos de roles de usuarios.
Administrador. Es el usuario con mayor privilegio de los existentes y permite realizar cualquier tipo de operación sobre el TPV que la Caja haya autorizado. Usuario. Permite realizar sólo consultas sobre la consola de administración. En ningún caso podrá modificar la configuración, ordenar operaciones, anularlas, … Desarrollador. Este usuario es temporal, es decir, a la hora de darlo de alta hay que ponerle una fecha de caducidad a partir de la cual no tendrá acceso a la aplicación. Los privilegios son idénticos al administrador a excepción de la consulta y creación del usuario, a cuyo apartado no tiene acceso. La funcionalidad de este usuario es realizar el desarrollo necesario en el TPV y configurarlo como indique el comercio. Una vez realizado su trabajo, este usuario no debería de volver a entrar a la consola, salvo que sea autorizado por un usuario administrador.
Este apartado nos permite: Consutar los usuarios existentes Editar y modificarlos Borrarlos Crear nuevos usuarios
38
13.- DIRECCIONES DE SOPORTE TPV Si necesitan resolver cualquier duda relacionada con este producto, deben inicialmente ponerse siempre en contacto con su Caja de Ahorros. Para cualquier problema relacionado con la implementación del TPV virtual en su comercio, pueden ponerse en contacto con la dirección de correo electrónico
[email protected] y teléfono 915965328.
Le recomendamos que antes de contactar con el soporte del TPV de las Cajas de Ahorros consulte el apartado de preguntas frecuentes, ya que en la mayoría de los casos en ese apartado se encuentra la solución al problema.
39
ANEXO V. TARJETAS DE PRUEBAS Con el fin de que los comercios puedan comprobar el correcto funcionamiento de su aplicación, ponemos a su disposición en el entorno de PRUEBAS las siguientes tarjetas: 5540500001000004 5020470001370055 5020080001000006 4507670001000009
Caducidad: Caducidad: Caducidad: Caducidad:
AAAA12 (Diciembre del año en curso) AAAA12 (Diciembre del año en curso) AAAA12 (Diciembre del año en curso) AAAA12 (Diciembre del año en curso)
CVV2: 989 CVV2: 989 CVV2: 989 CVV2: 989
AAAA será sustituido por el año en curso. Las tarjetas se renuevan anualmente. Transcurrido el año en curso, simplemente aumentar un año la fecha.
Acerca de la petición de datos La petición de estos dos datos (fecha de caducidad y número de tarjeta), ya bien sea desde el servidor del comercio o bien desde el servidor CECA mediante las paginas a personalizar puede realizarse de distintas formas, así por ejemplo es aconsejable solicitar la fecha a través de un combo de forma que el cliente solo debe elegir una fecha y no se preocupa del formato. Es importante indicar que la fecha de caducidad a introducir en el campo “Caducidad” debe ser estrictamente en el formato AAAAMM, aunque en las páginas se solicite de otra forma, se tendrá que componer a posteriori este formato. El número de tarjeta (campo PAN) deberá ser un número entero sin caracteres extraños o espacios en blanco.
A partir del 1 de Abril de 2006 la nueva política de seguridad para comercio electrónico obligará a los comercios que quieran solicitar los datos de tarjeta al cliente y que no quieran delegar esta función en el TPV virtual, deban contar con una autorización expresa de la caja correspondiente y cumplir las condiciones de seguridad y tratamiento de la información impuestas por cada entidad.
A partir del 1 de diciembre de 2008 la nueva política de seguridad para comercio electrónico obligará a que todas las operaciones de comercio electrónico sean tramitadas con el valor del CVV2/CVC2 de la tarjeta. Más información en anexo IV Petición de CVV2/CVC2.
40
ANEXO VI. PAGO SEGURO 3D-SECURE. En el siguiente Anexo se explicar el funcionamiento de un comercio que opera bajo la normativa 3D-Secure. Los comercios que utilicen este sistema podrán utilizar estos logos en su comercio, además deben incluirlo en la página de pago personalizada.
Implementación del pago 3D-Secure Este sistema se puede resumir en la securización de la persona que está utilizando la tarjeta con la que se está realizando el intento de pago. Esta securización puede ser por diferentes canales en función de las especificaciones de cada entidad. ¿Qué clientes pueden realizar un pago 3D-Secure? Solamente podrán realizar pagos de este tipo los clientes cuya entidad (emisora de la tarjeta) soporte este tipo de pago y que previamente le haya dado de alta su tarjeta en este sistema. Cada entidad podría adoptar distintas soluciones, de forma, que no existirá una única manera de proceder. El cliente siempre deberá consultar el manual de funcionamiento facilitado por su entidad o bien dirigirse a su entidad financiera para solucionar las dudas sobre el funcionamiento del software. ¿Qué comercio puede soportar este tipo de pago? Todos los comercios que actualmente tienen contratado el TPV virtual CECA podrán utilizar este sistema previo contacto con la caja donde tengan concertado el servicio. ¿Qué aporta este sistema al Comercio? Todas las operaciones realizadas bajo este sistema no podrán sufrir retrocesos, es decir el comercio tiene garantizado el pago y la responsabilidad de la operación se trastada al emisor de la tarjeta en caso de repudio. En ciertos casos puntuales, y ante la certeza de que un comercio escudado en la garantía de pago ha iniciado una actividad fraudulenta (o ha relajado sus mecanismos de control del fraude permitiendo a un tercero una actividad fraudulenta en el mismo), los sistemas internacionales o nacionales pueden acordar su pérdida de la garantía de pago durante un periodo determinado de tiempo, así como imponerle otras penalizaciones.
¿Cómo se realiza esta autenticación? Como comentábamos anteriormente este proceso puede diferir dependiendo de la entidad. Como ejemplo el sistema propuesto por CECA es a través de la confirmación de compra desde la BE del cliente. Esta confirmación es suficiente para garantizar que la tarjeta empleada en el pago es propiedad de la persona identificada.
41
Pantalla de activación de la identificación de cliente que presenta el TPV virtual.
42
43
44
ANEXO VIII: TRATAMIENTO DE ERRORES. En las páginas de error se puede visualizar un código de error de rechazo de la operación, ya bien sea debido a la propia aplicación o bien al rechazo por parte del emisor de la operación. Este código viene recogido en el parámetro “COD_AUT”, que para las compras correctas siempre será de valor “000” y para las anulaciones correctas “400” (“900” para anulaciones parciales). El resto de valores representa un código de error. Cod. Autorización 0 1 2 5 6 7 9 10 12 13 14 15 16 17 18 20 21 22 23 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Mensaje Operación aprobada COMUNICACION ON-LINE INCORRECTA ERROR AL CALCULAR FIRMA ERROR. Error en el SELECT COMERCIOS ERROR. Faltan campos obligatorios ERROR. MerchantID inexistente ERROR. No se pudo conectar a ORACLE ERROR. Tarjeta errónea FIRMA: %s-%s OPERACION INCORRECTA ERROR. Error en el SELECT OPERACIONES ERROR. Operación inexistente ERROR. Operación ya anulada ERROR AL OBTENER CLAVE ERROR. El ETILL no acepta el pedido ERROR. Tipo de moneda no valido. La operación debe realizarse en Euros ERROR. El comercio tiene un filtro que no permite esta operación ERROR. El comercio tiene un filtro que no permite esta operación ERROR. Operación UCAF no autorizada. Importe (%d) mayor del limite establecido (%d). ERROR. Datos no numéricos ERROR. Datos no alfa-numéricos ERROR en el calculo del MAC ERROR en el calculo del MAC [%s - %s][cadena:%s] ERROR. Usuario o password no valido. ERROR. Tipo de moneda no valido. La operación debe realizarse en Euros. ERROR. Importe no Integer. ERROR. Operación no realizable 100. ERROR. Formato CVV2/CVC2 no valido. ERROR. Debe especificar el CVV2/CVC2 de su tarjeta. ERROR. CVV2 no Integer. ERROR. En estos momentos no es posible continuar sin cvc2/cvv2 ERROR. ERROR en la operatoria del comercio. ERROR. Tipo de moneda no valido. La operación debe realizarse en Euros. ERROR. El comercio solo puede realizar pagos en Euros ERROR. Moneda o conversión no valida para esta tarjeta.[%d] ERROR. Moneda o conversión no valida.[%d] ERROR. Conversión a Euros no válida [%s][%s]. ERROR. El comercio no dispone de esta opción. ERROR. Respuesta Errónea del Gestor de operaciones. [%d][%s].
45
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 100 101 104 106
ERROR. No es posible continuar con la preautorizacion. ERROR. Error de comunicaciones Lu´s. No es posible finalizar la operación. ERROR. TimeOut SEP. No es posible finalizar la operación. ERROR. SEP devuelve un 20 ERROR. No es posible finalizar la operación. ERROR. Error inesperado. No es posible finalizar la operación [%d]. ERROR. Respuesta Errónea de SEP. No es posible finalizar la operación. ERROR. No es posible continuar con la preautorización. ERROR. Error en el proceso de Autentificación. No retroceda en el navegador. Debe volver al comercio y reintentar el pago. ERROR. Entidad no disponible. Inténtelo dentro de unos minutos ERROR. Error en el proceso de Autentificación. Respuesta PAREQ no valida [%d]. No retroceda en el navegador. Debe volver al comercio y reintentar el pago. ERROR. Error en el proceso de Autentificación. Respuesta PAREQ de su entidad no valida: %s,TXSTATUS ERROR. Fallo en el proceso de Autentificación. Es necesario una identificación positiva para finalizar el proceso de compra: %s,TXSTATUS ERROR. Fallo en el proceso de Autentificación. El comercio no acepta pagos no seguros: %s. Póngase en contacto con la entidad emisora de su tarjeta.,TXSTATUS ERROR. En estos momentos no es posible iniciar un pago seguro ERROR. Comercio seguro. Su tarjeta no admite autentificación y no puede operar en este comercio [%s]. Póngase en contacto con la entidad emisora de su tarjeta. ERROR. No es posible iniciar un pago seguro y el importe supera el máximo permitido (%f
