Document

1

TPV VIRTUAL 4.7 MANUAL DE IMPLEMENTACION PARA COMERCIOS

Caja Mediterráneo.

Avda. Oscar Espla, 37 � 03007 Alicante � Tel.: 902.100.112 Email: [email protected]

id46776481 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com

pdfMachine A pdf writer that produces quality PDF files with ease!

Produce quality PDF files in seconds and preserve the integrity of your original documents. Compatible across nearly all Windows platforms, simply open the document you want to convert, click “print”, select the

“Broadgun pdfMachine printer” and that’s it! Get yours now!

mailto:[email protected]

http://www.pdfmachine.com?cl

2

CONTENIDO CONTENIDO ................................................................................................................................. 2 1.- INTRODUCCIÓN: ..................................................................................................................... 2

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 TPV��. 19 8.- COMUNICACIÓN ON-LINE ................................................................................................... 26

Comunicación online con respuesta requerida: ......................................................................... 28 9.- CONSULTA ONLINE DE OPERACIONES REALIZADAS: ...................................................... 30 10.- COMUNICACIÓN BATCH DE LAS OPERACIONES REALIZADAS ...................................... 31 11.- ANULACIÓN DE OPERACIONES......................................................................................... 32

Anulación parcial desde WEB del Comercio. ............................................................................ 34 12.- DIRECCIONES DE SOPORTE TPV ..................................................................................... 37 ANEXO 0. RUTINA DEL CÁLCULO DE LA FIRMA ANTIGUA: ..................................................... 38

Propósito .................................................................................................................................. 38 Sintaxis .................................................................................................................................... 38 Formas habituales de Uso y requisito del hosting ..................................................................... 39

ANEXO I. INSTRUCCIONES DE INSTALACIÓN EN UNIX/LINUX ............................................... 40 ANEXO II. INSTRUCCIONES DE INSTALACIÓN EN WINDOWS NT.- ........................................ 42 ANEXO III. INSTRUCCIONES DE INSTALACIÓN EN JAVA.- ...................................................... 44 ANEXO IV. Ejemplo de implementación en Perl - PHP................................................................ 45 ANEXO V. TARJETAS DE PRUEBAS.......................................................................................... 51 ANEXO VI. PAGO SEGURO 3D-SECURE................................................................................... 52 ANEXO VII CONSOLA DE ADMINISTRACIÓN TPV VIRTUAL PARA COMERCIOS.................... 55 ANEXO VIII: TRATAMIENTO DE ERRORES. ............................................................................. 65 ANEXO IX: PETICIÓN DE CVV2/CVC2 ........................................... ¡Error! Marcador no definido. ANEXO X. OPERATORIA MULTIMONEDA ................................................................................. 68 ANEXO XI: GESTOR DE OPERACIONES................................................................................... 71 ANEXO XII: OPERATORIA AMEX (AMERICAN EXPRESS) ........................................................ 74 PREGUNTAS FRECUENTES. ..................................................................................................... 77 RECOMENDACIONES. ............................................................................................................... 79 CONTROL DE VERSIONES: ........................................................... ¡Error! Marcador no definido.

1.- INTRODUCCIÓN:





3

En este documento se describen las características de la versión 4.5 del TPV virtual ofrecido por CAM/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 CAM/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 4.1 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 CAM/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.

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





4

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 CAM/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 CAM/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.





5

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. Instalar en el hosting los ficheros necesarios para calcular la firma que será enviada al TPV. La

firma es un campo encriptado a partir de una serie de campos que se utiliza en el pago y que servirá para comprobar la autenticidad de los datos recibidos del comercio basándose en una clave de encriptación única. (Ver apartado 5 RUTINA DEL CÁLCULO DE LA FIRMA y anexos 1,2 y 3 para saber como se instala)

6. 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 CAM/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)

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 CAM/CECA su URL. (Ver apartado 8 Comunicación on-line)





6

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.


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.

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 opciones. -. El banco que corresponda no permite continuar sin autentificarte





7

-. 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.





8

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 8 10 4 3 2

TPV Virtual 5 6 9

Pasarela SET/SEP





9

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 CAM/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.

4. El cliente rellena el formulario y al pulsar el botón Aceptar, la información es enviada al

TPV virtual instalado en CAM/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.





10

Pago en comercio electrónico Seguro (3D-Secure) El esquema básico de funcionamiento es el siguiente:

Comercio Cliente 5 4 3 2 7 13 14 6 16

Identificación Titular 9 TPV Virtual 10 12 15 7 8

11 BANK Server

Pasarela SET/SEP

1





11

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 CAM/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.

4. El cliente rellena el formulario y al pulsar el botón Aceptar, la información es enviada al TPV virtual instalado en CAM/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.





12

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.6753030012614888330000000000019782120035304709122214340106007000") 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) <INPUT NAME="Cifrado" TYPE=hidden VALUE="SHA1"> <INPUT NAME="Firma" TYPE=hidden VALUE="Valor calculado de la firma"> y la firma calculada con SHA1 concatenando los parámetros Clave_encriptacion+MerchantID+AcquirerBIN+TerminalID+Num_operacion+Importe+TipoMoneda+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





13

Importe: 500 TipoMoneda: 978 Exponente: 2 Referencia: URL_OK: http://www.midominio.es URL_NOK: http://www.midominio.es -->Cadena_sha1: 998888881119500280000554052000000031235009782SHA1http://www.ceca.eshttp://www.ceca.es -->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+TipoMoneda+Exponente+Referencia




http://www.midominio.es

http://www.midominio.es


14

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 Requerido/

Opcional Longitud Descripción

MerchantID Requerido 9 Identifica al comercio. Facilitado por la caja en el proceso de alta

AcquirerBIN Requerido 10 Identifica la caja. Facilitado por la caja en el proceso de alta.

TerminalID Requerido 8 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,�

Num_operacion Requerido 50 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 Requerido 10 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.

TipoMoneda Requerido 3 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

Exponente Requerido 1 Actualmente siempre será 2 URL_OK Requerido 500 URL completa (http://�). Es la URL determinada por el

comercio a la que CAM/CECA devolverá el control en el caso de que la operación finalice correctamente.

URL_NOK Requerido 500 URL completa (http://�) Es la URL determinada por el comercio a la que CAM/CECA devolverá el control en el caso de que la operación no pueda realizarse por algún motivo.

Firma Requerido 256 Es una cadena de caracteres calculada mediante una rutina proporcionada por CAM/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.

Idioma Opcional 1 Código alfanumérico de idiomas Pago_soportado Requerido SSL SSL Pago_elegido Opcional 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á.

Descripcion Opcional 1000 Campo reservado para mostrar información extra en la página de pago.

PAN Opcional 19 Nº de tarjeta del cliente. Solamente necesario si el cliente solicita estos datos.

Caducidad Opcional 6 Fecha de Caducidad. Formato AAAAMM. Solamente





15

necesario si el cliente solicita estos datos. CVV2 Opcional CVC2 de la tarjeta. Solamente necesario si el cliente

solicita estos datos. Referencia Opcional 30 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 CAM/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.

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 2.- Catalán 5.- Valenciano 6.- Inglés 7.- Francés 8.- Alemán 9.- Portugués 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.





16

6.2 Ejemplos de formularios

Ejemplo de llamada en la que los datos de tarjeta son solicitados por el TPV

<HTML> <HEAD> <TITLE>Página de pago</TITLE> </HEAD> <BODY> <FORM ACTION="https://pgw.ceca.es/cgi-bin/tpv" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> <INPUT NAME="MerchantID" TYPE=hidden VALUE=##MerchantID##> <INPUT NAME="AcquirerBIN" TYPE=hidden VALUE=##AcquirerBIN##> <INPUT NAME="TerminalID" TYPE=hidden VALUE=##TerminalID##> <INPUT NAME="URL_OK" TYPE=hidden VALUE=##URL_OK##> <INPUT NAME="URL_NOK" TYPE=hidden VALUE=##URL_NOK##> <INPUT NAME="Firma" TYPE=hidden VALUE=##Firma##> <INPUT NAME="Num_operacion" TYPE=hidden VALUE=##Num_operacion##> <INPUT NAME="Importe" TYPE=hidden VALUE=##Importe##> <INPUT NAME="TipoMoneda" TYPE=hidden VALUE=978> <INPUT NAME="Exponente" TYPE=hidden VALUE=2> <INPUT NAME=�Pago_soportado� TYPE=hidden VALUE=SSL> <INPUT NAME=�Idioma� TYPE=hidden VALUE=�1�> <CENTER> <INPUT TYPE="submit" VALUE="Comprar"> </CENTER> </FORM> </BODY> </HTML>

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.





17

Ejemplo de llamada en la que los datos de tarjeta son solicitados por el comercio

<HTML> <HEAD> <TITLE>Página de pago</TITLE> </HEAD> <BODY> <FORM ACTION="https://pgw.ceca.es/cgi-bin/tpv" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> Tarjeta:<INPUT NAME="PAN" TYPE=text VALUE=><br> Caducidad:<INPUT NAME="Caducidad" TYPE=text VALUE=><br> CVV2/CVC2:<INPUT NAME="CVV2" TYPE=text VALUE=><br> <INPUT NAME="MerchantID" TYPE=hidden VALUE=##MerchantID##> <INPUT NAME="AcquirerBIN" TYPE=hidden VALUE=##AcquirerBIN##> <INPUT NAME="TerminalID" TYPE=hidden VALUE=##TerminalID##> <INPUT NAME="URL_OK" TYPE=hidden VALUE=##URL_OK##> <INPUT NAME="URL_NOK" TYPE=hidden VALUE=##URL_NOK##> <INPUT NAME="Firma" TYPE=hidden VALUE=##Firma##> <INPUT NAME="Num_operacion" TYPE=hidden VALUE=##Num_operacion##> <INPUT NAME="Importe" TYPE=hidden VALUE=##Importe##> <INPUT NAME="TipoMoneda" TYPE=hidden VALUE=978> <INPUT NAME="Exponente" TYPE=hidden VALUE=2> <INPUT NAME=�Pago_soportado� TYPE=hidden VALUE=SSL> <INPUT NAME=�Pago_elegido� TYPE=hidden VALUE=SSL> <INPUT NAME=�Idioma� TYPE=hidden VALUE=�1�> <CENTER> <INPUT TYPE="submit" VALUE="Comprar"> </CENTER> </FORM> </BODY> </HTML>


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





18

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 CAM/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.




https://pgw.ceca.es/cgi-bin/tpv

http://tpv.ceca.es:8000/cgi-bin/tpv


19

7.- PÁGINAS TPV. Por cada comercio, el TPV virtual maneja al menos un juego de páginas HTML (varios en el caso de multi-idioma) compuesto por 4 páginas, que dependiendo de la configuración del comercio pueden no ser necesarias: MerchantID_ssl.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.

MerchantID_ok.html 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.





20

MerchantID_error_atras.html Pagina de error, permite reintentar la operación.





21

MerchantID_error_maximo.html Pagina de error. Informa del error y se continúa a la dirección

indicada en el campo URL_NOK indicada por el comercio.





22





23

7.1.- Descripción de las páginas

MerchantID_ssl.html: Página mostrada por el TPV virtual en el caso de que el parámetro Pago_soportado contenga el valor SSL.. Permitirá introducir los datos de la tarjeta de crédito/débito. Deberá ser de la forma:

<HTML> <HEAD><TITLE>Comercio Electrónico</TITLE></HEAD> <BODY> <FORM ACTION="https://pgw.ceca.es/cgi-bin/tpv" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> <INPUT NAME="MerchantID" TYPE=hidden VALUE=##MERCHANTID##> <INPUT NAME="AcquirerBIN" TYPE=hidden VALUE=##ACQUIRERBIN##> <INPUT NAME="TerminalID" TYPE=hidden VALUE=##TERMINALID##> <INPUT NAME="URL_OK" TYPE=hidden VALUE=##URL_OK##> <INPUT NAME="URL_NOK" TYPE=hidden VALUE=##URL_NOK##> <INPUT NAME="Firma" TYPE=hidden VALUE=##FIRMA##> <INPUT NAME="Num_operacion" TYPE=hidden VALUE=##NUMOPERACION##> <INPUT NAME="Importe" TYPE=hidden VALUE=##IMPORTE##> <INPUT NAME="TipoMoneda" TYPE=hidden VALUE=##TIPOMONEDA##> <INPUT NAME="Exponente" TYPE=hidden VALUE=##EXPONENTE##> <INPUT NAME="Pago_soportado" TYPE=hidden VALUE=##PAGO_SOPORTADO##> <INPUT NAME="Pago_elegido" TYPE=hidden VALUE=SSL> <INPUT NAME="Idioma" TYPE=hidden VALUE=##IDIOMA##> <B>Tarjeta:</B> <INPUT TYPE="text" NAME="PAN" size=19 maxlength=19><P> <P><B>Fecha de caducidad:</B> <INPUT TYPE="text" NAME="Caducidad" size=6 maxlength=6><P> <B>CVV2/CVC2:</B> <INPUT TYPE="text" NAME="CVV2" size=3 maxlength=3><P> <P><CENTER><INPUT TYPE="submit" VALUE="Comprar"> <INPUT TYPE="reset" VALUE="Borrar"></CENTER></FORM> </BODY> </HTML>


El formato del campo Caducidad tiene que ser AAAAMM. De cara a evitar errores de tecleo se puede añadir scripts en Javascript para tratar de evitar estos problemas y facilitar la introducción de estos datos por parte del cliente, por ejemplo solicitando la fecha de caducidad a través de un combo que posteriormente formatea la fecha en el formato exigido. En este caso el comercio debe asegurar su compatibilidad con las distintas versiones de navegadores.

Nota importante: Si desde dichas páginas HTML se utilizan gráficos en formato GIF ó JPG, deberán referenciarse como ../images_<MerchantID>/<gráfico>, con objeto de poder separar en el TPV Virtual los gráficos que corresponden a cada Comercio





24

MerchantID_OK.html: Página HTML mostrada por el TPV virtual en el caso de que la compra finalice correctamente. Podrá contener los siguientes literales, que serán sustituidos por el TPV virtual por sus valores correspondientes, antes de ser visualizada:

##COD_AUT## .- Código de Autorización devuelto por la pasarela SET/SEP. En las compras

será siempre 000. ##NUM_AUT## .- Número de Autorización devuelto por la pasarela SET/SEP. ##REFERENCIA## .- Referencia devuelta por la pasarela SET/SEP. Este dato es imprescindible

para realizar cualquier tipo de reclamación y/o anulación de la compra. ##IMPORTE## .- Es el importe de la compra recibido en la orden de compra. ##NUM_OPERACION## .- Es la referencia del pedido asignada por el comercio y recibida en la

orden de compra. ##FECHA## .- Fecha y hora de la operación. Hora local de la pasarela de pagos CAM/CECA. ##URL_OK## .- Es la URL determinada por el comercio a la que CAM/CECA devolverá el control

en este caso.


MerchantID_error_atras.html: Página mostrada por el TPV virtual en el caso de que la compra finalice con error y no se haya alcanzado el número máximo de reintentos definidos por el Comercio. El comercio tiene libertad para eliminar la opción de reintentos y modificar el comportamiento de la página. Es aconsejable permitir reintentar la operación así como continuar hacia la URL_NOK del comercio. Podrá contener los siguientes literales, que serán sustituidos por el TPV virtual por sus valores correspondientes antes de ser visualizada:

##MENSAJE## .- Mensaje de Error devuelto por el TPV virtual ó por la pasarela SET/SEP. ##NUM_OPERACION## .- Es la referencia del pedido asignada por el comercio y recibida en la

orden de compra. ##FECHA## .- Fecha y hora de la operación. Hora local de la pasarela de pagos CAM/CECA. ##URL_NOK## .- Es la URL determinada por el comercio a la que CAM/CECA devolverá el

control en este caso. AVISO: En los comercios seguros (Verfied by Visa & MasterCard Secure Code) tras introducir los datos bancarios se inicia el proceso de autenticación, en caso de fallo se presenta esta pagina de error_atras. Esta página puede disponer un javascript con la posibilidad de reintento, pero puede no funcionar ya que al reconducir al sistema de autenticación y este trabajar bajo sesiones de navegación va a rechazar la operación. El cliente debe volver al comercio o a la página de pago inicial para reintentar la operación.






25

MerchantID_error_maximo.html: Página mostrada por el TPV virtual en el caso de que la compra finalice con error y se haya alcanzado el número máximo de reintentos definidos por el comercio. Podrá contener los siguientes literales, que serán sustituidos por el TPV virtual por sus valores correspondientes antes de ser visualizada:

##MENSAJE## .- Mensaje de Error devuelto por el TPV virtual ó por la pasarela SET/SEP. ##NUM_OPERACION## .- Es la referencia del pedido asignada por el comercio y recibida en la

orden de compra. ##FECHA## .- Fecha y hora de la operación. Hora local de la pasarela de pagos CAM/CECA. ##URL_NOK## .- Es la URL determinada por el comercio a la que CAM/CECA devolverá el

control en este caso.


Otras páginas: Existen otro juego de páginas opcionales que se explican más adelante para el caso de comercios que quieran realizar anulaciones de operaciones de forma automática.

Idiomas En caso de utilizar la opción de multi-idioma, estas páginas se llamarán:

MerchantID-Idioma_ok.html MerchantID-Idioma_error_atras.html MerchantID-Idioma_error_maximo.html MerchantID-Idioma_ssl.html

Códigos de idioma:

1.- Español 2.- Catalán 5.- Valenciano 6.- Inglés 7.- Francés 8.- Alemán 9.- Portugués 10.- Italiano





26

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:

Nombre Longitud Descripción

MerchantID 9 Identifica al comercio. Facilitado por la caja en el proceso de alta AcquirerBIN 10 Identifica la caja. Facilitado por la caja en el proceso de alta. TerminalID 8 Identificativo del Terminal. Actualmente para todos los TPV virtuales es

siempre 00000003. Num_operacion 50 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 10 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.

TipoMoneda 3 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.

Exponente 1 Actualmente siempre será 2 Referencia 30 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.

Firma 256 Es una cadena de caracteres calculada mediante una rutina escrita en �C� proporcionada por CAM/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.

Num_aut 6 Valor asignado por la entidad emisora a la hora de autorizar una operación.

Idioma 2 Idioma de la operación Pais 3 Código ISO del país de la tarjeta que ha realizado la operación Descripcion 200 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.





27





28

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 CAM/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: <HTML> <HEAD> <TITLE>Respuesta correcta a la comunicación ON-LINE</TITLE> </HEAD> <BODY> $*$OKY$*$ </BODY> </HTML> Para ver la configuración actual del comercio:

Desde la Web de Administración pulse Dentro de los datos mostrados se puede visualizar la configuración actual del comercio.

Esta URL se debe indicar en el formulario de alta del TPV virtual. Los cambios posteriores deben solicitarse a la Caja o bien enviando un correo con el Merchantid y la nueva dirección a la dirección [email protected], indicando la configuración de respuesta requerida y si se trata del entorno de pruebas, real o ambos. En caso de no indicar entorno, la configuración se realizará tanto en pruebas como en real.




mailto:[email protected],


29

Esquema del proceso

Operación Correcta

Se presenta la pagina OK

Se va a la URL_OK

Operación Correcta

Se envía formulario a la dirección especificada


Se va a la URL_OK

Operación Correcta

Se envía formulario a la dirección especificada

Se captura la respuesta (25 sg)

Incluye el string OKY No responde o no incluye el string OKY


Se va a la URL_OK

Se presenta la pagina Error atrás con ERROR en la comunicación on line.

Sin comunicación on line Y sin respuesta requerida

Con comunicación on line y sin respuesta requerida

Con comunicación on line y respuesta requerida





30

9.- CONSULTA ONLINE DE OPERACIONES REALIZADAS: Con el fin de que los Comercios puedan consultar y/o anular las operaciones efectuadas por sus clientes, CAM/CECA ha instalado en uno de sus servidores WEB seguros, una aplicación accesible desde cualquier navegador, que permite realizar las siguientes funciones*:

Identificación del comercio.- Solicita un usuario y una contraseña para permitir el acceso únicamente a los usuarios autorizados.

Modificación de la contraseña.- Permite que el usuario cambie su contraseña de acceso.

Consulta de operaciones.- Permite realizar búsquedas sobre las operaciones correctamente realizadas de acuerdo a uno ó varios de los siguientes criterios:

a) Tipo de operación.- Compra ó Devolución. b) Fecha.- Permite especificar una fecha concreta ó un intervalo de fechas. c) Número de operación.- Permite especificar un número de operación concreto ó un intervalo de

números de operación. d) Importe.- Permite especificar un importe concreto ó un intervalo de importes. e) Tarjeta.- Permite especificar un número de tarjeta.

El resultado de la búsqueda se muestra en una tabla en la que se visualiza una fila por cada operación que cumpla los criterios solicitados. En cada fila se muestran los siguientes campos:

f) 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.

Anulación de operaciones.- Permite anular una operación de compra realizada por

alguno de los clientes. Simular compras .- A través de un asistente podrá efectuar pagos contra su comercio

simulando un proceso normal de compra. Las URLs correspondientes a los dos entornos en los que se encuentra instalada esta aplicación son: https://www.ceca.es/comercio/identificacion.html PRODUCCION http://www.desa.ceca.es/comercio/identificacion.html DESARROLLO

Direcciones alternativas: Producción: https://pgw.ceca.es/admincomercios/inicio.html Desarrollo: http://tpv.ceca.es:8000/admincomercios/inicio.html

En el anexo VII de esta manual, dentro del apartado Administración TPV Virtual para Comercios, existe una descripción más detallada sobre la funcionalidad y el uso de esta consola de administración.




https://www.ceca.es/comercio/identificacion.html

http://www.desa.ceca.es/comercio/identificacion.html

https://pgw.ceca.es/admincomercios/inicio.html

http://tpv.ceca.es:8000/admincomercios/inicio.html


31

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, CAM/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 CAM/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. Tipo de operación. Puede tomar los valores C (compra) o D (devolución). 2. Fecha. Fecha y hora en formato DD/MM/AAAA hh:mm:ss. 3. Número de operación. Número de operación asignado por el comercio. 4. Importe. Importe sin formatear. 5. 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






32

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 las páginas de Gestión ON-LINE de operaciones efectuadas descrita anteriormente, 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:


MerchantID 9 Identifica al comercio. Facilitado por la caja en el proceso de alta AcquirerBIN 10 Identifica la caja. Facilitado por la caja en el proceso de alta. TerminalID 8 Identificativo del Terminal. Actualmente siempre para todos los TPV

virtuales es 00000003. Num_operacion 50 Identifica para el comercio la operación, nº de pedido, factura, albarán,


Importe 10 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.

Tipo_moneda 3 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.



Firma 256 Es una cadena de caracteres calculada mediante una rutina �C� proporcionada por CAM/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.

Idioma 1 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.

Pagina 50 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 Anulación correcta anulacion_error_atrás.html Problemas en la anulación si el campo Idioma no está relleno, ó anulacion-<Idioma>_ok.html Anulación correcta anulacion-<Idioma>_error_atrás.html Problemas en la anulación





33

Si va relleno, las páginas HTML mostradas por el CGI son:

<Pagina>_ok.html Anulación correcta <Pagina>_error_atrás.html Problemas en la anulación si el campo Idioma no está relleno, ó <Pagina>-<Idioma>_ok.html Anulación correcta <Pagina>-<Idioma>_error_atrás.html 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 CAM/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 PRODUCCION http://tpv.ceca.es:8000/cgi-bin/tpvanular DESARROLLO

En la página siguiente se muestra un ejemplo de cómo debería ser este formulario HTML:

<HTML> <HEAD> <TITLE>Página de anular operaciones</TITLE> </HEAD> <BODY> <FORM ACTION="https://pgw.ceca.es/cgi-bin/tpvanular" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> <INPUT NAME="MerchantID" TYPE=hidden VALUE=##MerchantID##> <INPUT NAME="AcquirerBIN" TYPE=hidden VALUE=##AcquirerBIN##> <INPUT NAME="TerminalID" TYPE=hidden VALUE=##TerminalID##> <INPUT NAME="Firma" TYPE=hidden VALUE=##Firma##> <INPUT NAME="Num_operacion" TYPE=hidden VALUE=##Num_operacion##> <INPUT NAME="Importe" TYPE=hidden VALUE=##Importe##> <INPUT NAME="TipoMoneda" TYPE=hidden VALUE=978> <INPUT NAME="Exponente" TYPE=hidden VALUE=2> <INPUT NAME="Referencia" TYPE=hidden VALUE=##Referencia##> <CENTER> <INPUT TYPE="submit" VALUE="Enviar"> <INPUT TYPE="reset" VALUE="Borrar"> </CENTER> </FORM> </BODY> </HTML>





https://pgw.ceca.es/cgi-bin/tpvanular

http://tpv.ceca.es:8000/cgi-bin/tpvanular


34

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 CAM/CECA la URL (incluyendo protocolo) del mismo. Este CGI será invocado con los siguientes parámetros:


MerchantID 9 Identifica al comercio. Facilitado por la caja en el proceso de alta AcquirerBIN 9 Identifica la caja. Facilitado por la caja en el proceso de alta. TerminalID 8 Identificativo del Terminal. Actualmente para todos los TPV virtuales es

siempre 00000003. Num_operación 50 Identifica para el comercio la operación, nº de pedido, factura, albarán,


Importe 10 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.

Tipo_moneda 3 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.



Firma 256 Es una cadena de caracteres calculada mediante una rutina �C� proporcionada por CAM/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 administración WEB y procede a la anulación de una operación observará la posibilidad de anular la operación o realizar anulación parcial.





35

1-. Opción antigua: Anular Operación (totalmente) 2-. Nueva opción que solo aparece en el caso de tener activa la opción correspondiente. Pulsando sobre la opción �Anular parcialmente�

Pulsar sobre Anular





36

Restricciones:

Solo los comercios autorizados por su Caja podrán utilizar esta opción. El importe debe ser menor o igual al importe original de la operación. Solo se permite una sola anulación por operación. Esta puede ser total o parcial.

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




http://tpv.ceca.es:8000/cgi-bin/tpvanularparcialmente

https://pgw.ceca.es/cgi-bin/tpvanularparcialmente


37

12.- DIRECCIONES DE SOPORTE TPV Si necesitan resolver cualquier duda relacionada con este producto, deben ponerse en contacto con Caja Mediterráneo � Teleservicios, en el correo electrónico [email protected] o por teléfono llamando al 902.100.112..

Le recomendamos que antes de contactar con el soporte del TPV 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.






38

ANEXO 0. RUTINA DEL CÁLCULO DE LA FIRMA ANTIGUA:

Propósito

Cálculo de firma electrónica basada en algoritmo DES. El resultado es una cadena de caracteres calculada mediante una rutina proporcionada por CAM/CECA al comercio a través de una librería. En principio, esta librería estará disponible para entornos UNIX (SOLARIS, HP-UX, AIX y LINUX), WINDOWS-NT/2000 y JAVA, por lo cual queda resuelta la portabilidad a todas las máquinas en las que esté instalada la máquina virtual JAVA.

El algoritmo de cifrado para el calculo de este parámetro es propietario de CAM/CECA y por tanto no es posible obtener el mismo resultado con ningún algoritmo de cifrado que proporcionan los distintos lenguajes de programación, debe por tanto utilizar la librería, ejecutable o clase java facilitados para obtener este valor. Esto implica que el hosting contratado requiera de unas características mínimas para hacer uso de este software.

Sintaxis int calcular_firma (ClaveCifrado, MerchantID, AcquirerBIN, TerminalID, Num_operacion, Importe, TipoMoneda, Exponente, Referencia, Firma) char *ClaveCifrado; char *MerchantID; char *AcquirerBIN; char *TerminalID; char *Num_operacion; char *Importe; char *TipoMoneda; char *Exponente; char *Referencia; char *Firma; Descripción Compone una cadena de caracteres a partir de los parámetros MerchantID, AcquirerBIN, TerminalID, Num_operacion, Importe, TipoMoneda, Exponente y Referencia y la cifra utilizando un algoritmo propietario de CAM/CECA, y dejando el resultado en la dirección apuntada por el parámetro Firma. El valor del campo ClaveCifrado será proporcionado por CAM/CECA, después de dar de alta un nuevo TPV. Este valor es UNICO para cada comercio, DISTINTO en pruebas que en real, no viaja por la red y por tanto garantiza que la firma solamente ha podido ser generada por el comercio. La clave de cifrado puede ser consultada a través de la consola del TPV-Operaciones (Ver anexo VII Administración TPV Virtual para Comercios) Esta rutina podrá ser invocada por el Servidor de Comercio en dos casos:

* Al preparar el formulario correspondiente a la página de pago. Se utilizará para enviar el valor del parámetro Firma. En este caso el parámetro Referencia deberá contener el valor cadena vacía (��). Dicho campo se utilizará para posibles anulaciones.





39

* Cuando la pasarela de pagos le comunique que un cliente ha realizado correctamente una operación de compra. Se utilizará para desencriptar el valor del parámetro Firma y comprobar que es correcta. En este caso, el parámetro Referencia contine el valor indicado por la pasarela.

* Códigos devueltos: La rutina devuelve un valor 0 si la operación se ha realizado correctamente y un valor negativo (-1) en caso contrario.

Formas habituales de Uso y requisito del hosting

ASP (clásico): El servidor debe permitir el registro de las DLLs facilitadas, algunos hosting ya disponen de estas librerías instaladas en sus servidores. Debe ponerse en contacto con el hosting para saber si se puede cumplir este requisito.

Alternativas. En caso que el hosting no permita instalar estas DLLs, se puede optar por la utilización de PERL a través del programa ejecutable �calculo*� o bien llamar a este mismo ejecutable desde ASP. Ver ejemplos posteriores.

.net: No es necesario registrar DLLs, existe una DLL específica que permite obtener el cifrado sin necesidad de registro, por tanto el hosting no debe tener ninguna característica específica PERL: Se puede obtener el resultado de la firma a través de un ejecutable denominado �calculo*�, este deberá situarse en el directorio �cgi-bin�. Ver ejemplo de uso posterior. PHP: Dado que no es posible desde PHP llamar a una función definida dentro de una librería, se deberá utilizar o bien el registro de las DLLs o el programa calculo*. Si el servidor tiene registrado las DLLs se puede utilizar estas para el calculo de la firma (ver ejemplo). Lo habitual es la utilización del programa �calculo� a través de la función EXEC() o SYSTEM(), por tanto el hosting debe tener una política SAFE_MODE a off y no tener disabled las funciones anteriores o bien una política SAFE_MODE definida mediante un SAFE_MODE_EXEC_DIR debiéndose alojar el programa calculo en este directorio. Esta información puede visualizarse en el típico phpinfo(). JAVA: Se facilita una clase java definida en un Packaged, por tanto no ser requiere ningún tipo de requisito específico. El programa calculo varia con el sistema operativo, estando disponible para Windows, Linux 32 y 64 bits. El de 64 bits es compatible con Linux de 32 bits pero Linux tiene que tener instalada la librería lib-a32. Consultar los anexos 1,2 y 3 que aparecen al final de este manual para ver como se instala la librería.





40

ANEXO I. INSTRUCCIONES DE INSTALACIÓN EN UNIX/LINUX Se facilita desde el TPV virtual un ejecutable compatible con la mayoría de las distribuciones Linux, el comercio solo debe subir en binario este programa ejecutable vía FTP a su servidor y concederle los permisos de ejecución para poder utilizarlo. En algunos casos excepcionales hay que recurrir a compilar el programa calculo con la librería en el propio servidor. En esos casos los pasos a seguir son los siguientes: Copiar la librería libtpv.a en cualquier directorio del Servidor al que se tenga acceso.

A continuación, para compilar el programa (suponiendo que está escrito en "C", como suele ser lo más habitual sobre UNIX), se debe añadir a la lista de librerías con las que se debe "linkar", la nueva librería libtpv.a de la forma:

cc -o <programa_resultado> <programa_fuente> -L<directorio_de_instalacion> -ltpv Supongamos que tenemos librería libtpv.a y el código fuente, denominado calculo.c (ver ejemplo posterior) en el mismo directorio. Para compilarlo simplemente pondríamos. cc -o calculo calculo.c -L./ -ltpv De esta forma crearíamos en el mismo directorio un ejecutable calculo que deberíamos dotar de los permisos necesarios para su ejecución y que seria el encargado de generar la firma electrónica a incorporar en nuestro formulario. Se recomienda la limitación de los parámetros de entrada (ver definiciones de longitud en apartado 4.1

Por lo general no es necesario compilar este programa. Se facilita desde el TPV virtual un ejecutable compatible con la mayoría de las distribuciones Linux, el comercio solo debe subir en binario este programa ejecutable vía FTP a su servidor y concederle los permisos de ejecución para poder utilizarlo.





41

Ejemplo sencillo de programa calculo: #include <stdio.h> main (argc, argv) int argc; unsigned char **argv; { if ( argc != 10) { printf (" ---ERROR EN LA SINTAXIS ---\n"); printf ("Sintaxis: calculo <Password> <MerchantID> <AcquirerBIN> <TerminalID> <Num_operacion> <Importe> <TipoMoneda> <Exponente> <Referencia>\n"); exit (1); }else{ unsigned char Password [9]; unsigned char Firma [1001]; unsigned char MerchantID [10]; unsigned char AcquirerBIN [11]; unsigned char TerminalID [9]; unsigned char Num_operacion [51]; unsigned char Importe [16]; unsigned char TipoMoneda [4]; unsigned char Exponente [2]; unsigned char Referencia [51]; memset (Password, 0, sizeof (Password)); memset (Firma, 0, sizeof (Firma)); memset (MerchantID, 0, sizeof (MerchantID)); memset (AcquirerBIN, 0, sizeof (AcquirerBIN)); memset (TerminalID, 0, sizeof (TerminalID)); memset (Num_operacion, 0, sizeof (Num_operacion)); memset (Importe, 0, sizeof (Importe)); memset (TipoMoneda, 0, sizeof (TipoMoneda)); memset (Exponente, 0, sizeof (Exponente)); memset (Referencia, 0, sizeof (Referencia)); strncpy (Password, argv [1], sizeof (Password)); strncpy (MerchantID, argv [2], sizeof (MerchantID)); strncpy (AcquirerBIN, argv [3], sizeof (AcquirerBIN)); strncpy (TerminalID, argv [4], sizeof (TerminalID)); strncpy (Num_operacion, argv [5], sizeof (Num_operacion)); strncpy (Importe, argv [6], sizeof (Importe)); strncpy (TipoMoneda, argv [7], sizeof (TipoMoneda)); strncpy (Exponente, argv [8], sizeof (Exponente)); strncpy (Referencia, argv [9], sizeof (Referencia)); calcular_firma (Password,MerchantID,AcquirerBIN,TerminalID,Num_operacion,Importe,TipoMoneda,Exponente,Referencia,Firma); printf (Firma); exit (0); } }






42

ANEXO II. INSTRUCCIONES DE INSTALACIÓN EN WINDOWS NT.- Consiste en hacer lo siguiente: - Copiar la librería LIBTPV.DLL en el directorio C:\WINNT\SYSTEM32. - Copiar la librería TPV.DLL en cualquier otro directorio, por ejemplo en C:\. Es aconsejable que el nombre del directorio donde la instale no contenga espacios. - La librería que debe registrar es esta última, con el comando: regsvr32 C:\TPV.DLL (suponiendo que está en el directorio C:\) Esto es así porque la librería TPV.DLL busca otra librería llamada LIBTPV.DLL desarrollada en CAM/CECA y que contiene la función "calcular_firma" que es la que contiene el algoritmo con la firma digital. Para que TPV.DLL encuentre a LIBTPV.DLL, esta última debe de estar en el directorio C:\WINNT\SYSTEM32. Algunos hosting no permiten el registro de DLLs, una alternativa es la llamada al programa ejecutable �calculo� desde una shell en ASP tal y como se muestra a continuación o bien la utilización de un paso intermedio entre ASP y el TPV mediante un formulario en PERL (ver ejemplo) dim tpv, x, firma, precioTpv dim programa, objShell, objScriptExec, salida ' Utilizo el calculo.exe en vez de la dll � Falta de añadir el parámetro con la clave �clave_encriptacion� programa = "W:\TPV\calculo.exe " & MerchantID & " " & AcquirerBIN & " " & TerminalID & " " & Num_operacion & " " & Importe & " " & TipoMoneda & " " & Exponente & " " & Referencia Set objShell = CreateObject("WScript.Shell") Set objScriptExec = objShell.Exec(programa) firma = objScriptExec.StdOut.ReadAll if inStr(firma, "ERROR") then response.write "Hay un error en la firma<br>" response.write programa & "<br>" response.end 'else ' response.write "Estado: " & objScriptExec.Status & " - Salida: " & firma ' response.end end if






43

EJEMPLO ASP En está página, se incluye un ejemplo de código "ASP" desde el que se llama a la rutina "calcular_firma" y se compone y ejecuta la página HTML de conexión con el TPV virtual.


<head>

<script language=javascript>

function lanzar()

{document.forms[0].submit();}

</script>

</head> <body>

<%

set tpv = CreateObject("tpv_commerce.tpv_commerce.1")

tpv.clave_encriptacion = Variable1 (solo en la version 3)

tpv.MerchantID = Variable2

tpv.AcquirerBIN = Variable3

tpv.TerminalID = Variable4

tpv.Num_operacion = Variable5

tpv.Importe = Variable6

tpv.TipoMoneda = Variable7

tpv.Exponente = Variable8

tpv.Referencia=""

x = tpv.calcular_firma

if x <> 0 then

Response.Write x

Response.write "<br>"

Response.Write "Error en el calculo de la firma"

Response.End

end if

firma = tpv.Firma

set tpv = Nothing

%>

<form method=post action="http://tpv.ceca.es:8000/cgi-bin/tpv" >

<input type=hidden name="MerchantID" value="<%=Variable2%>">

<input type=hidden name="AcquirerBIN" value="<%=Variable3%>">

<input type=hidden name="TerminalID" value="<%=Variable4%>">

<input type=hidden name="URL_OK" value="<%=Direccion html de ok%>">

<input type=hidden name="URL_NOK" value="<%=Direccion html de NOK%>">

<input type=hidden name="Firma" value="<%=firma%>">

<input type=hidden name="Importe" value="<%=variable6%>">

<input type=hidden name="Idioma" value="<%=cod_idioma%>">

<input type=hidden name="TipoMoneda" value="<%=Variable7%>">

<input type=hidden name="Exponente" value="<%=Variable8%>">

<input type=hidden name="Pago_soportado" value="SSL">

<input type=hidden name="Descripcion" value="<%=descripcion%>">

<input type=hidden name="Num_operacion" value="<%=Variable5%>">

</form>

<SCRIPT language=javascript>lanzar(); </script>

</body></html>





44

ANEXO III. INSTRUCCIONES DE INSTALACIÓN EN JAVA.- Se facilita el jar �ceca.tpv.jar� La librería TPV3.class se compone de una variable pública TPV3.firma (String [] ) y de un método TPV3.calcular_firma () al que se le deben pasar los siguientes argumentos:

Clave de encriptación: Es la clave de encriptación del comercio. Esta debe ser proporcionada por CAM/CECA una vez que el comercio este implementado y se quieran realizar pruebas o bien entrar en producción. MerchantID, AcquirerBIN, TerminalID, Num_operación, Importe, TipoMoneda, Num_operación, Referencia: ya han sido descritos en versiones anteriores.

TPV3.calcular_firma, compone una cadena de caracteres a partir de los parámetros MerchantID, AcquirerBIN, TerminalID, Num_operacion, Importe, TipoMoneda, Exponente y Referencia, la cifra utilizando un algoritmo DES modo CBC, le aplica una codificación de 8 a 7 bits, y deja el resultado en el string TPV3.firma. Esta rutina podrá ser invocada por el Servidor de Comercio en dos casos:

Al preparar el formulario correspondiente a la página de pago. En este caso el parámetro Referencia deberá contener el valor cadena vacía (��) y cuando la pasarela de pagos le comunique que un cliente ha realizado correctamente una operación de compra. En este caso, el parámetro Referencia deberá contener el valor indicado por la pasarela.

Ejemplo en JAVA:


import es.ceca.TPV3.*; import java.io.*; class calculo { public static void main(String[] args) { try { TPV3 firma = new TPV3 (args[0]); System.out.println ("Firma:"+firma.calcularFirma (args[1], args[2], args[3], args[4],args[5], args[6], args[7], args[8]) ); } catch (Exception E) { System.out.println (" ------------------------------------"); System.out.println (" E R R O R D E S I N T A X I S"); System.out.println (" ------------------------------------"); System.out.println (""); System.out.println ("$ java calculo <passwd> <merchantid> <acquierbin> <terminalid> <num_operacion> <importe> <tipo_moneda> <exponente> <referencia>"); } } }





45

El resultado que obtenemos si ejecutamos este ejemplo es el siguiente: java calculo 12345678 1 2 3 4 5 6 7 8

Firma:

73609E5FA0529DC59EEF7220657C99DCCC75BFBFF92B78BD439C2FF31CC0CAEFF13A60FB805D31D81DB0C

8A22F26E44F04EB2AC842E2CEACC6E6040D6FD046CA1C59AC15F040294277766DB86E0AF7422F281855DDA

32E673AF0131D646918D12F15BF7C0749DB5F41156906A76E909A2C1352B586DD0D21C6E5F7566AE907F9

ANEXO IV. Ejemplo de implementación en Perl - PHP Se trata de un ejemplo de implementación del TPV virtual muy simple, compuesto por los siguientes ficheros: Comercio.html.- Página HTML en la que se recogen varios campos del pedido (número de operación e importe). Cuando se pulsa sobre el botón enviar, envía estos parámetros al CGI comercio.pl escrito en Perl. Es el siguiente:

Evidentemente se deberá de CAMBIAR EL ACTION DEL FORMULARIO a la dirección particular en cada caso donde se encuentre el programa en perl.





46

Código fuente mínimo: <HTML> <HEAD> <TITLE>Ejemplo</TITLE> </HEAD> <BODY> <FORM ACTION="cgi-bin/comercio.pl" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> Nº Operación: <INPUT NAME="Num_operacion" TYPE=text VALUE=><br> Importe:<INPUT NAME="Importe" TYPE=text VALUE=><br> <INPUT TYPE="submit" VALUE="Enviar"> <INPUT TYPE="reset" VALUE="Borrar"> </FORM> </BODY> </HTML>






47

Código perl Recoge los parámetros que envía la anterior pagina html (nº operación e importe), calcula la firma a partir de los datos identificativos del comercio más de la operación y genera un formulario que nos envía. Evidentemente se DEBERAN CAMBIAR LOS DATOS IDENTIFICATIVOS DEL COMERCIO.


#!/usr/bin/perl # Perl script para la implementaciÆn del TPV Virtual de CECA # a travÅs del programa "calculo". # use CGI; $cgi = new CGI; $NO = $cgi->param ('Num_operacion'); $I = $cgi->param ('Importe'); $TM = "978"; $E = "2"; # DescripciÆn del Comercio. $PWD = "07495119"; #Password o clave de encriptacion $MID = "111950028"; #identificación comercio MerchantID $ABIN = "0000554052"; #identificación de la caja AquirerBIN $TID = "00000003"; #idenficicación del terminal TerminalID $calculo = './calculo'; # LocalizaciÆn del programa calculo (Asegurese de que es correcta la ruta) # Calculo de la firma para la operaciÆn $FR = `$calculo $PWD $MID $ABIN $TID $NO $I $TM $E ""`; # URL´s de vuelta al comercio $URL_OK = "http://www.sucomercio.com/graciasporsucompra.html"; $URL_NOK = "http://www.sucomercio.com/errorensucompora.html"; #Genera formulario para enviar a la pasarela. print "Content-type: text/html\n\n"; print "<HTML>"; print "<HEAD>"; print "<TITLE>Página de pago</TITLE>"; print "<script language=javascript>"; print "function lanzar(){document.forms[0].submit();}</script>"; print "</HEAD>"; print "<BODY>"; print "<FORM ACTION=\"http://tpv.ceca.es:8000/cgi-bin/tpv\" METHOD=\"POST\" ENCTYPE=\"application/x-www-form-urlencoded\">"; print "<INPUT NAME=\"MerchantID\" TYPE=hidden VALUE=$MID>"; print "<INPUT NAME=\"AcquirerBIN\" TYPE=hidden VALUE=$ABIN>"; print "<INPUT NAME=\"TerminalID\" TYPE=hidden VALUE=$TID>"; print "<INPUT NAME=\"Num_operacion\" TYPE=hidden VALUE=$NO>"; print "<INPUT NAME=\"Importe\" TYPE=hidden VALUE=$I>"; print "<INPUT NAME=\"TipoMoneda\" TYPE=hidden VALUE=$TM>"; print "<INPUT NAME=\"Exponente\" TYPE=hidden VALUE=$E>"; print "<INPUT NAME=\"Firma\" TYPE=hidden VALUE=$FR>"; print "<INPUT NAME=\"URL_OK\" TYPE=hidden VALUE=$URL_OK>"; print "<INPUT NAME=\"URL_NOK\" TYPE=hidden VALUE=$URL_NOK>"; print "<INPUT NAME=\"Pago_soportado\" TYPE=hidden VALUE=SSL>"; print "<INPUT NAME=\"Idioma\" TYPE=hidden VALUE=1>"; print "<CENTER>"; print "<font face=\"Verdana, Arial, Helvetica, sans-serif\" size=4 color=\"#006699\"\" > "; print "<br><br><br> Conectando con entidad financiera. Por favor, espere...</font>"; print "</CENTER>"; print "</FORM><script language=javascript>lanzar();</script>"; print "</BODY>"; print "</HTML>";





48

El programa calculo es quien tras recibir 9 parámetros devolverá la firma. IMPORTANTE: Este código, como todos los que aparecen en el manual es solamente un ejemplo muy sencillo. Cada comercio tendrá total libertad de modificar el programa y adecuarlo a las necesidades y requerimientos de seguridad que considere oportunas. Se recomienda la restricción de los parámetros de entrada para aumentar la seguridad del sistema, tanto en el código Perl, PHP como en el programa Cálculo. Código PHP

<html>

<head>

<title>Ejemplo de PHP - Lanza Datos a CECA</title>

<script language=javascript>

function lanzar()

{

document.forms[0].submit();

}

</script>

</head>

<body>

<br><br>

<font face="Verdana" size="3" color="#0f0084">

<center><b>Procesando operación. <br>Enviando datos a entidad Bancaria.<br><br><br><br>Por favor espere...</center>

<?php

$Clave = "07495113223239";

$MerchantID = "111950323232028";

$AcquirerBIN = "000055403252";

$TerminalID = "00000003";

$Referencia = "";

$URL_OK = "http://www.ceca.es";

$URL_NOK = "http://www.ceca.es";

$string = "./calculo $Clave $MerchantID $AcquirerBIN $TerminalID $Num_operacion $Importe $Tipomoneda $Exponente \"\" ";

$resultado = exec($string);

?>

<FORM ACTION="http://tpv.ceca.es:8000/cgi-bin/tpv" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded">

<input name="MerchantID" type=hidden value=<?php echo $MerchantID ?>>

<input name="AcquirerBIN" type=hidden value=<?php echo $AcquirerBIN ?>>

<input name="TerminalID" type=hidden value=<?php echo $TerminalID ?>>

<input name="Num_operacion" type=hidden value=<?php echo $Num_operacion ?>>

<input name="Importe" type=hidden value=<?php echo $Importe ?>>

<input name="TipoMoneda" type=hidden value=<?php echo $Tipomoneda ?>>

<input name="Exponente" type=hidden value=<?php echo $Exponente ?>>

<input name="URL_OK" type=hidden value=<?php echo $URL_OK ?>>

<input name="URL_NOK" type=hidden value=<?php echo $URL_NOK ?>>

<input name="Firma" type=hidden value=<?php echo $resultado ?>>

<input name="Idioma" type=hidden value=1>

<input name="Pago_soportado" type=hidden value=SSL>

<SCRIPT language=javascript>

lanzar();

</script>

</FORM>

</body> </html>





49


El ejemplo en PHP es muy similar al ejemplo en PERL, aunque hay varias formas de hacer lo mismo, la clave esta en la ejecución del programa calculo que devolverá la firma a través de la instrucción �exec()�. Primero se compone una cadena con la ejecución del programa y las variables necesarias para el calculo de la firma y después se ejecuta ese string mediante la función PHP exec() que devuelve el resultado a una variable. $string = "./calculo $Clave $MerchantID $AcquirerBIN $TerminalID $Num_operacion $Importe $Tipomoneda $Exponente \"\" "; $resultado = exec($string); Es importante destacar que no es lo mismo $Referencia = ��; $string = "./calculo $Clave $MerchantID $AcquirerBIN $TerminalID $Num_operacion $Importe $Tipomoneda $Exponente $Referencia "; que poner directamente las comillas en la línea de ejecución, ya que de la primera forma interpreta que falta una variable y por tanto devolverá un error de sintaxis.. Utilización de PHP con DLLs <html> <head> <title>Ejemplo de PHP - Lanza Datos a CECA</title> <script language=javascript> function lanzar(){ document.forms[0].submit(); } </script> </head> <body> <br><br><font face="Verdana" size="3" color="#0f0084"><center><b>Procesando operación. <br>Enviando datos a entidad Bancaria.<br><br><br><br>Por favor espere...</center> <?php $tpv = new COM('tpv_commerce.tpv_commerce.1') or die("Imposible calcular firma digital"); $tpv->Clave_Encriptacion = "11439044"; $tpv->MerchantID = "111950028"; $tpv->AcquirerBIN = "0000554052"; $tpv->TerminalID = "00000003"; $tpv->Num_Operacion = "4"; $tpv->Importe = "5"; $tpv->TipoMoneda = "978"; $tpv->Exponente = "2"; $tpv->Referencia = ""; $tpv->Calcular_Firma(); $firmadigital = $tpv->Firma; $tpv = null; $resultado = $firmadigital; ?> <br> <FORM ACTION="http://tpv.ceca.es:8000/cgi-bin/tpv" METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> <input name="MerchantID" type=hidden value=<?php echo $MerchantID ?>> <input name="AcquirerBIN" type=hidden value=<?php echo $AcquirerBIN ?>> <input name="TerminalID" type=hidden value=<?php echo $TerminalID ?>> <input name="Num_operacion" type=hidden value=<?php echo $Num_operacion ?>> <input name="Importe" type=hidden value=<?php echo $Importe ?>> <input name="TipoMoneda" type=hidden value=<?php echo $Tipomoneda ?>> <input name="Exponente" type=hidden value=<?php echo $Exponente ?>> <input name="URL_OK" type=hidden value=<?php echo $URL_OK ?>>





50

<input name="URL_NOK" type=hidden value=<?php echo $URL_NOK ?>> <input name="Firma" type=hidden value=<?php echo $resultado ?>> <input name="Idioma" type=hidden value=1> <input name="Pago_soportado" type=hidden value=SSL> <SCRIPT language=javascript>lanzar();</script> </FORM> </body> </html>






51

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 Caducidad: AAAA12 (Diciembre del año en curso) CVV2: 989 5020470001370055 Caducidad: AAAA12 (Diciembre del año en curso) CVV2: 989 5020080001000006 Caducidad: AAAA12 (Diciembre del año en curso) CVV2: 989 4507670001000009 Caducidad: AAAA12 (Diciembre del año en curso) 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 CAM/CECA mediante las paginas del TPV virtual 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.





52

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. 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 CAM/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.


¿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 CAM/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.





53

Pantalla de activación de la identificación de cliente que presenta el TPV virtual.





54





55

ANEXO VII 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.

Acceso Las direcciones establecidas para el acceso son las siguientes:

PRUEBAS http://tpv.ceca.es:8000/admincomercios/inicio.html REAL https://pgw.ceca.es/admincomercios/inicio.html

El usuario y password de acceso son los mismos que para la anterior administración. Problemas de ACCESO: La primera vez que se accede a este entorno el password de acceso coincide con el propio número de comercio. Tal y como se indica mediante un aviso, es conveniente cambiar el password en ese mismo momento, indicando una clave alfanumérica de al menos ocho caracteres. Cuando accede a la pantalla anterior dispone de un minuto para intentar el acceso. Superado ese tiempo deberá volver a cargar la página e intentar el acceso. IMPORTAMTE: El acceso a esta administración requiere que el navegador permita una conexión segura de 128 bytes, la ejecución de JavaScript y permitir grabar cookies. En caso de que algunas de estas condiciones no se cumpliesen, podría no acceder, no visualizarse correctamente o no funcionar correctamente.




http://tpv.ceca.es:8000/admincomercios/inicio.html

https://pgw.ceca.es/admincomercios/inicio.html


56

Significado de los iconos.

Significado de Icono a Icono

PRIMER ICONO. Cambio de Password Pulsando sobre el icono tendremos acceso a una pantalla donde se solicitará el nuevo password por duplicado así como el antiguo password, siendo necesario los 3 parámetros mencionados para poder actualizar su contraseña de acceso a este entorno de administración.





57

SEGUNDO ICONO. Datos del comercio Visualiza los datos principales del comercio. Primeramente los datos no modificables, después los datos de comportamiento a la hora de realizar la compra. Estos datos (activación / desactivación) de comunicación on line y respuesta requerida pueden ser modificados mediante el contacto con la caja o bien a la dirección de soporte. IMPORTANTE: Está pantalla puede carecer de algunas opciones si la Caja así lo entiende.





58

CUARTO ICONO. Consulta de Operaciones y Anulaciones Desde está opción se podrá realizar la búsqueda de operaciones, realizar anulaciones y ver más datos sobre la operación. Al pulsar sobre el icono aparecerá una pantalla con un calendario del mes en curso.

Pulsar sobre el día. Se obtiene el informe de ese día.

Pulsar sobre el mes. Se obtiene el informe del mes.

Añadir condiciones de búsqueda. Se puede restringir la búsqueda por parámetros como nº de operación, tarjeta e importe.





59

Búsqueda en intervalo temporal. Esta búsqueda funciona de diferente forma. Cuando se pulsa sobre la opción, aparecen 2 calendarios como los que se ven en la figura, primero se elige la primera fecha (el �desde�), posteriormente la segunda fecha (el �hasta�). Una vez rellenas las dos fechas se pulsa sobre �Realizar consulta�. También se puede añadir condiciones de búsqueda como en el caso anterior.

Aspecto de la búsqueda en un intervalo temporal y con condiciones de búsqueda restrictivas.





60

Resultados de la búsqueda. Se devuelven en un listado con el aspecto siguiente. +Datos � Visualiza más datos sobre la operación.

Anulación. Se pide confirmación de anulación.





61

Opciones Disponibles en la página .

Visualización del importe en Pesetas. Al pasar el ratón sobre el importe se visualiza el importe en Pesetas

Se visualizan todos los intentos de compra llegados hasta medios de pago. No aparecerán los intentos con tarjetas no numéricas o caducadas.

Guardar estos datos bien como fichero plano (fichero txt) o bien como una pagina web como la está visualizando. Solo funciona en IE.

Imprime está pagina.





62

QUINTO ICONO. Búsqueda de operaciones. Se podrá realizar búsquedas de operaciones por ciertos criterios de selección. Estas búsquedas son de operaciones recientes, es decir, unos últimos 90 días, para informes anteriores deberá editarlos desde la opción anterior.

Resultados: Los resultados se muestran en un listado.





63

SEXTO ICONO. Simulación de Compra

Desde está opción puede simularse una operación de compra. Es una forma rápida de comprender como funciona el TPV virtual y como se conecta con el final de cualquier carrito de compra. Realmente se trata de una compra REAL (en el entorno de producción), para ello el comercio deberá conocer el número de tarjeta y fecha de caducidad que el cliente la habrá facilitado por otro medio. Cuando el cliente pulsa sobre el icono solamente tiene 2 campos obligatorios, un identificador de operación (numeró de operación) y un Importe en céntimos de Euros. Además si lo desea puede añadir una pequeña descripción. El TPV virtual es multi-idioma, por lo que se puede especificar una pagina a mostrar.

Importante: Esta simulación de compra puede no ser compatible con la comunicación on line y respuesta requerida. Depende de la configuración del comercio. Opción de crear enlace de compras para compras de correo.

Esta opción esta pensada específicamente para la opción de venta por correo. El funcionamiento es el mismo, rellenar el formulario superior y al pulsar se crea un enlace que se enviara por correo al cliente. Este lo recibirá y tras pulsar sobre este enlace se conecta a la WEB donde se realizará el pago.





64

Pulsando vemos el enlace generado a enviar al cliente.

IMPORTANTE: Este enlace será valido durante 30 días. Si se quiere aumentar o disminuir este periodo póngase en contacto con soporte.

SÉPTIMO ICONO. Salida. Cierre de sesión. Si pulsamos sobre el icono se borran las cookies de sesión y salimos de la aplicación.





65

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 Mensaje

0 Operación aprobada 1 COMUNICACION ON-LINE INCORRECTA 2 ERROR AL CALCULAR FIRMA 5 ERROR. Error en el SELECT COMERCIOS <%d> 6 ERROR. Faltan campos obligatorios 7 ERROR. MerchantID inexistente <%d> 9 ERROR. No se pudo conectar a ORACLE <%d>

10 ERROR. Tarjeta errónea 12 FIRMA: %s-%s 13 OPERACION INCORRECTA 14 ERROR. Error en el SELECT OPERACIONES <%d> 15 ERROR. Operación inexistente <%d> 16 ERROR. Operación ya anulada <%d> 17 ERROR AL OBTENER CLAVE 18 ERROR. El ETILL no acepta el pedido 20 ERROR. Tipo de moneda no valido. La operación debe realizarse en Euros 21 ERROR. El comercio tiene un filtro que no permite esta operación 22 ERROR. El comercio tiene un filtro que no permite esta operación 23 ERROR. Operación UCAF no autorizada. Importe (%d) mayor del limite establecido (%d). 19 ERROR. Datos no numéricos 20 ERROR. Datos no alfa-numéricos 21 ERROR en el calculo del MAC 22 ERROR en el calculo del MAC [%s - %s][cadena:%s] 23 ERROR. Usuario o password no valido. 24 ERROR. Tipo de moneda no valido. La operación debe realizarse en Euros. 25 ERROR. Importe no Integer. 26 ERROR. Operación no realizable 100. 27 ERROR. Formato CVV2/CVC2 no valido. 28 ERROR. Debe especificar el CVV2/CVC2 de su tarjeta. 29 ERROR. CVV2 no Integer. 30 ERROR. En estos momentos no es posible continuar sin cvc2/cvv2 31 ERROR. ERROR en la operatoria del comercio. 32 ERROR. Tipo de moneda no valido. La operación debe realizarse en Euros. 33 ERROR. El comercio solo puede realizar pagos en Euros 34 ERROR. Moneda o conversión no valida para esta tarjeta.[%d] 35 ERROR. Moneda o conversión no valida.[%d] 36 ERROR. Conversión a Euros no válida [%s][%s]. 37 ERROR. El comercio no dispone de esta opción.





66

38 ERROR. Respuesta Errónea del Gestor de operaciones. [%d][%s]. 39 ERROR. No es posible continuar con la preautorizacion. 40 ERROR. Error de comunicaciones Lu´s. No es posible finalizar la operación. 41 ERROR. TimeOut SEP. No es posible finalizar la operación. 42 ERROR. SEP devuelve un 20 ERROR. No es posible finalizar la operación. 43 ERROR. Error inesperado. No es posible finalizar la operación [%d]. 44 ERROR. Respuesta Errónea de SEP. No es posible finalizar la operación. 45 ERROR. No es posible continuar con la preautorización.

46 ERROR. Error en el proceso de Autentificación. No retroceda en el navegador. Debe volver al comercio y reintentar el pago.

47 ERROR. Entidad no disponible. Inténtelo dentro de unos minutos

48 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.

49 ERROR. Error en el proceso de Autentificación. Respuesta PAREQ de su entidad no valida: %s,TXSTATUS

50 ERROR. Fallo en el proceso de Autentificación. Es necesario una identificación positiva para finalizar el proceso de compra: %s,TXSTATUS

51 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

52 ERROR. En estos momentos no es posible iniciar un pago seguro

53 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.

54 ERROR. No es posible iniciar un pago seguro y el importe supera el máximo permitido (%f <= %s). [Resultado: %s]

55 ERROR. En este momento no es posible iniciar un pago seguro. [Resultado: %s]

56 ERROR. No es posible iniciar un pago seguro y el importe supera el máximo permitido (%f <= %s). [Resultado: %s]

57 ERROR. En este momento no es posible iniciar un pago seguro y el importe supera el máximo permitido (%f <= %s). [Resultado: %s]

58 ERROR. En este momento no es posible iniciar un pago seguro. [Resultado: %s] 59 ERROR. El comercio tiene un filtro que no permite esta operación. 60 ERROR. El Comercio solo admite pago seguro. Necesita autentificarse para continuar. 61 ERROR. Operación segura no permitida. Importe (%14.2f) mayor del limite establecido (%14.2f). 62 ERROR. El comercio tiene un filtro que no permite esta operación.(Filtro2:%d)

63 ERROR. El comercio no acepta pagos Visa no autentificados. Póngase en contacto con su entidad para activar este tipo de pago.

64 ERROR. El comercio no acepta pagos MasterCard no autentificado. Póngase en contacto con su entidad para activar este tipo de pago.

65 ERROR. El comercio no acepta pagos no autentificados. Póngase en contacto con su entidad para activar este tipo de pago.

66 ERROR. Error de proceso. El comercio no acepta pagos no autentificados. Póngase en contacto con su entidad para activar este tipo de pago.

67 ERROR. Operación segura no autorizada. Importe (%14.2f) mayor del limite establecido (%14.2f).

68 ERROR. Respuesta Errónea del Gestor de operaciones. Operación anulada [%s].Gestor: [%d][%s].

69 ERROR. Operatoria UCAF no valida. Póngase en contacto con su comercio o caja. 100 Tarjeta no válida (en negativos) 101 Tarjeta caducada 104 Tarjeta no válida (electrón)





67

106 Tarjeta no válida (reintentos de PIN) 111 Número de tarjeta mal tecleado (check) 112 Tarjeta no válida (se exige PIN) 114 No admitida la forma de pago solicitada 116 Saldo insuficiente 118 Tarjeta no válida (no existente en ficheros) 120 Tarjeta no válida en este comercio 121 Disponible sobrepasado 123 Número máximo de operaciones superado 125 La tarjeta todavía no es operativa 180 Tarjeta no soportada por el sistema 190 Operación no realizable (resto de casos) 400 Anulación aceptada 480 Anulación por TO aceptada sin encontrar la operación original 900 Devolución aceptada 904 Operación no realizable (error de formato) 908 Tarjeta desconocida 909 Operación no realizable (error de sistema) 912 Su entidad no está disponible 913 Operación no realizable (clave duplicada) 914 No existe la operación a anular 930 Operación no realizable (caja merchant no válida) 931 Operación no realizable (comercio no dado de alta) 932 Operación no realizable (bin merchant no existe) 933 Operación no realizable (sector desconocido) 940 Ya recibida una anulación 944 Operación no realizable (sesión no válida) 948 Operación no realizable (fecha/hora inválida) 950 Devolución no aceptada 999 Operación no realizable (resto de casos)

El error más habitual será el 190 que es la denegación por el emisor de la tarjeta. El TPV pide la autorización a la entidad emisora y esta deniega sin especificar una causa exacta de denegación. Deberá el cliente ponerse en contacto con su entidad para saber la causa exacta, es esta la única forma de conocer la causa exacta de esta denegación





68

ANEXO X. OPERATORIA MULTIMONEDA Los comercios deben contar con la aprobación de su caja para poder implementar esta opción.

Para saber si disponen de esta opción basta comprobar que visualizan el siguiente icono en la web de administración.

La Caja podrá obligar a que el comercio sea consciente del cambio diario y obligue al comercio

a enviar la conversión exacta a Euros del importe enviado en otra moneda. EL TPV Virtual facilitará un tipo de cambio para 24 horas. La tabla es transparente y constante

para el comercio y también es visible desde la WEB de administración.

(i) Conversión 1 Euro USD (Dólar americano) 1,2911 GBP (Libra Esterlina) 0,6861 JPY (Yen Japonés) 138,9400 CHF (Franco Suizo) 1,5535

Los comercios pueden publicar sus precios en N monedas (al principio en libras,

posteriormente dólares). Los comercios deben facilitar siempre al TPV virtual el importe de la compra en la moneda en

la que quiera operar y su valor correspondiente en Euros en caso que su caja así lo exija. Ejemplo: Compra de 90 dólares Importe=90 TipoMoneda=840 Importe_euros=6971 Exponente=2

*Siempre será exponente 2, es decir, los dos últimos dígitos siempre y en todos los casos son céntimos de la moneda que sea y los importes números enteros





69

sin formatear.

a) Esquema de funcionamiento Se distinguen 2 escenarios de funcionamiento en función de si el comercio esta interesado en conocer el tipo de cambio aplicado o bien delega en el TPV la conversión a Euros de la moneda enviada en la petición de compra. Escenario 1: EL Comercio no informa de la conversión a Euros. Proceso de compra. El comercio simplemente envía el Importe y código de moneda en el que desea realizar el cobro. <INPUT TYPE=hidden name="Importe" VALUE=�3750�> <INPUT TYPE=hidden name="TipoMoneda" VALUE=�826�> <INPUT TYPE=hidden name="Exponente" VALUE=�2�> En este caso se interpreta que el comercio desea realizar una operación de 37,50 Libras esterlinas (código moneda 826). El TPV buscara la conversión adecuada a la operación y procesará la operación de forma transparente para el comercio. En resumen, el comercio tendrá un ingreso asociado en su cuenta de los euros correspondientes a la conversión aplicada y el cliente verá en los movimientos de su tarjeta un cargo de 37.50 Libras. Escenario 2: EL Comercio debe informar de la conversión a Euros.

Paso1: A las 18:00 horas, el TPV informará a través de la WEB de administración y mediante el envió de un email o fichero FTP en función de las preferencias del comercio, del cambio que será aplicado para las 24 horas del siguiente día. Paso 2: Una vez recibida esa información el comercio podrá incorporar ese cambio a sus tablas aunque no podrá �actualizar� este valor hasta la 0:00 horas para que el cambio sea efectivo.

TPV

Comercio

Paso1

Paso2

Paso3

18:00





70

Paso3: A partir de ese momento el comercio puede ofertar en su WEB los nuevos tipo de cambio y la operatoria en distintas monedas a sus clientes. Proceso de compra. El comercio añadirá al formulario de compra actual un nuevo campo denominado �Importe_euros� modificando el actual valor constante de TipoMoneda fijado en 978 (Euros) por el valor correspondiente. <INPUT TYPE=hidden name="Importe" VALUE=�3750�> <INPUT TYPE=hidden name=�Importe_euros� VALUE="2566"> <INPUT TYPE=hidden name="TipoMoneda" VALUE=�826�> <INPUT TYPE=hidden name="Exponente" VALUE=�2�> En este caso se interpreta que el comercio desea realizar una operación en Libras esterlinas (código moneda 826) donde 37,50 Libras que son 25,66Euros. En resumen, el comercio tendrá un ingreso asociado en su cuenta de 25,66� y el cliente verá en los movimientos de su tarjeta un cargo de 37.50 Libras. Consideraciones a tener en cuenta en este caso. 1 -. El TPV comprobará que el importe petición sea igual que el importe en euros por el factor de conversión, de lo contrario se rechaza

2) Importe_euros = (Importe / Factor _conversión) Aproximaciones: Si el comercio desea aproximar sus importes en Euros a importes �comerciales� en otra moneda, tal vez deberá operar al revés, es decir, si quiere que un producto sean 99 dólares, deberá aplicar la conversión a los 99 dólares y enviar el importe resultante en Euros. En ningún caso el TPV permite aproximaciones que no se correspondan estrictamente con los céntimos de euro (aproximación al tercer decimal, + o � 1 céntimo).

2 -. El comercio podrá publicar el precio en una moneda distinta al euro por cálculo directo del coste en euros aplicando el cambio del día o bien siguiendo el criterio que considere oportuno siempre y cuando cumpla el mínimo de cambio exigido. Otras consideraciones a tener en cuenta en ambos escenarios 1-. Operativa en Cuentas corrientes en monedas diferentes al Euro. El ingreso al comercio siempre será en Euros, por tanto, en caso de cuentas abiertas en moneda diferente debe hablar con su entidad para aclarar la operatoria y posibles comisiones por conversión de moneda 2-. Operaciones con tarjetas asociadas a cuentas en otra moneda a la enviada. El comercio debe tener en cuenta que si lanza una operación por ejemplo en dólares y el cliente efectúa el pago con una tarjeta asociada a una cuenta en euros, este observará un cargo diferente a la conversión establecida por el TPV ya que intervienen comisiones de terceros que el TPV desconoce en el momento de la operación, por tanto deberá explicar al cliente que seleccione siempre que pueda la moneda corriente de su cuenta, de lo contrario siempre pueden intervenir comisiones extras que el TPV desconoce.





71

ANEXO XI: GESTOR DE OPERACIONES

El acceso al gestor de operaciones debe ser aprobado por la Caja. Es un proceso diseñado para procesar operaciones complejas que requieran más de un pago. Los usos más comunes de este tipo de operaciones puedan ser pagos aplazados, suscripciones, pagos fraccionados, etc.�. El funcionamiento es el siguiente.

El comercio acuerda con la caja el tipo de pago que va a utilizar (no es algo que pueda definir el comercio, sino que es la Caja quien decide los tipos de pago que existen y que por tanto el comercio puede utilizar). Ahora mismo son los siguientes Tipo 1:

Pago aplazado. (Tipo A)

En el campo libre (datos operación) se le pasan los siguientes datos: - Fecha del pago aplazado (8 primeros dígitos) - Importe del pago aplazado (10 dígitos restantes)

Tipo 2: Pago 25/75, (Tipo B) es decir, se ha realizado el 25% del pago y se aplaza el 75% del

pago. Como indicamos, se ha realizado el primer pago y el segundo pago se realizará en la fecha

indicada por el campo libre, siendo el importe de este pago el triple del que nos pasa el TPV en el parámetro importe.

En el campo libre (datos operación) se le pasan los siguientes datos: - Fecha del pago aplazado (8 dígitos)

Tipo 3: Suscripción mensual con cuota fija. (Tipo 1)

Se realiza el primer pago y se programa un número de pagos (nº de subscripciones) con el importe pasado en el campo libre. Estos pagos pueden empezar el día 1 del próximo mes (nº meses gratis = 0) o aplazarse el número de meses indicados (nº meses gratis distinto de cero).

En el campo libre (datos operación) se le pasan los siguientes datos:

- Importe (10 dígitos) - Número de subscripciones (2 dígitos) - Número de meses gratis (2 dígitos)

Cada vez que los pagos lleguen a su fecha y sean lanzadas, se enviará un correo de confirmación al comercio con su resultado. Estos son los 3 tipos de pago existentes, cualquier otra tipo de casuística debe ser solicitada a la caja para que estudie si tiene sentido y apruebe su generación. Una vez el comercio este autorizada por su entidad al uso de esta opción, su utilización es muy sencilla. Solo debe añadir dos campos al formulario de compra tradicional. Por ejemplo, en este caso se trata de la operación con identificación 5342, de 50� y se quiere un segundo pago el 10 de Septiembre del 2010 de 200,01�. El comercio envía el formulario de compra habitual para una compra de 50� donde añade dos nuevos campos





72

Estos son los nuevos campos <INPUT NAME="Datos_operaciones" value="201009100000020001" size=20> <INPUT NAME="Tipo_operacion" TYPE=text size=1 VALUE="A"> Los tres posibles valores del campo TIPO son TIPO=A Pago Aplazado TIPO=B Pago 25/75 TIPO=1 Suscripción anual con cuota fija. El comercio debe personalizar la pagina para incluir esta campo, será la variable �##GESTOR##�, pudiendo mostrar un aspecto como el siguiente.

Que responde al siguiente código, donde en caso de una operación del gestor de operaciones se muestra las características del pago y en caso contrario, simplemente el literal �compra�.





73

<tr> <td align="left"> <font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#000000"> <b>Operacion:</b> </font> </td> <td align="left" > <font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#000000"> <b> <SCRIPT LANGUAGE="JavaScript"> if ("##GESTOR##" != "") document.write("##GESTOR##"); else document.write("Compra"); </script> </b> </font> </td> </tr> Cuando el comercio tiene activa esta opción en su administración WEB aparece un nuevo icono que le proporciona acceso al administrador de las operaciones realizadas por el gestor de operaciones y cuyo uso se comenta en el manual denominado �Consola Gestor de Operaciones.pdf� (solicitar a [email protected])




mailto:[email protected])


74

ANEXO XII: OPERATORIA AMEX (AMERICAN EXPRESS) Esta opción no está activada por defecto en ningún TPV. Si un comercio desea operar con este tipo de tarjetas debe realizar los siguientes pasos administrativos antes de realizar los cambios necesarios en la programación del TPV:

1. Contactar con su entidad para ver si es viable utilizar este tipo de tarjetas 2. Dirigirse a American Express (correo electrónico: [email protected]) y firmar un acuerdo

de adquirencia con esta Compañía 3. Contactar de nuevo con su entidad para que le habiliten este tipo de operaciones en la

administración del TPV

IMPORTANTE Cualquier tema administrativo, consulta de operaciones, reclamaciones, etc, deben ser resueltos entre American Express y el Comercio en función del contrato entre ambas partes y las leyes aplicables en cada momento, los abonos son realizados directamente por American Express al comercio sin pasar por la entidad adquirente del TPV Virtual.

El comercio por defecto no puede utilizar la operativa AMEX, debe contar con el visto bueno de su caja. Seguramente suponga un nuevo contrato entre la Caja � AMEX y el comercio, debe dirigirse a su oficina y tramitar el alta.

Una vez que el comercio ha realizado los trámites administrativos, desde el punto de vista del comercio el cambio más importante es la modificación de la pantalla para solicitar los datos de la tarjeta, donde el campo CVV2 pasa de denominarse CSC y es de 4 dígitos de longitud. Hay varias formas de hacerlo, tal vez lo más sencillo sea añadir un combo donde en función del tipo de tarjeta el valor introducido se añade al value del campo CVV2 en el caso de Visa/MasterCard y al value CSC en el caso de AMEX.






75

Para Visa y MasterCard <INPUT TYPE="text" NAME="CVV2" size=3 maxlength=3 >

Para American Express <INPUT TYPE="text" NAME="CSC" size=4 maxlength=4 >

Una vez el comercio tenga disponible la operatoria AMEX en la WEB de administración aparecerá el siguiente icono

Pulsando se accede a la pantalla de búsqueda de operaciones, por defecto se muestran las del ultimo mes, pero es posible establecer una búsqueda de operaciones en intervalo temporal.

Los resultados de la búsqueda aparecen en un listado donde es posible consultar más datos de la operación y realizar anulaciones. Listado de operaciones

Fecha abono: Amex abona las operaciones 2 días después de esta fecha Opción �+ Datos� Visualiza más información sobre la operación Opción �Anular� Realiza la devolución de la operación

IMPORTANTE El abono de estas operaciones es independiente del cierre diario del resto de operaciones. En el contrato firmado con AMEX se explicará el proceso, aunque en resumen el abono será dos días posterior a la fecha indicada en la autorización de la operación. Existen un documento proporcionado por AMEX denominado �REQUISITOS PARA UTILIZAR EL NOMBRE Y EL LOGO DE AMERICAN EXPRESS® EN SU SITIO WEB� que describe la forma de utilización de su marca y logo. Este documento debe ser consultado y las páginas a publicar deben de cumplir todos los





76

puntos .





77

PREGUNTAS FRECUENTES. Al intentar operar me aparece un error 190 Resto de casos El error 190 es el más habitual. Denegación por el emisor de la tarjeta. El TPV pide la autorización a la entidad emisora y esta deniega sin especificar una causa exacta de denegación. Deberá el cliente ponerse en contacto con su entidad para saber la causa exacta, es esta la única forma de conocer la causa exacta de esta denegación ya que es ajeno al propio funcionamiento del TPV. Si el fallo se produce en el entorno de pruebas probar de nuevo con otra tarjeta de las que aparece en el anexo V Tarjetas de pruebas. Al intentar operar me aparece un error �Faltan campos obligatorios� En el 99% de los casos este os debido a que el campo firma no está viajando o lo está haciendo sin contenido. Asegúrese de que viaja correctamente. Si la firma viaja pero no es correcta el error es otro. Este error también es debido por el campo Pago Soportado no viaja. Este campo actualmente es obligatorio y tiene que venir con valor SSL Por último, en el caso de que los datos de la tarjeta sean solicitados por el comercio el campo Pago_elegido debe viajar con el valor SSL y además tiene que enviar los datos de la tarjeta número, cvc2/cvv2 y fecha de caducidad. Al intentar operar me aparece una cadena con la firma enviada En realidad no devuelve la cadena de la firma sino que muestra la firma enviada, un guión y la firma esperada. Ello es debido que la firma no se ha calculado de la forma correcta. ¿Cómo puedo saber desde mi aplicación si la operación realizada ha sido correcta? Para ello existe la comunicación online. Consulte el apartado 8 Comunicación on-line de este manual. No es recomendable usar la URL_OK para esta tarea ya que entonces se depende de la navegación del usuario, es decir, de que el usuario pinche el botón ok, cosa que no siempre ocurre a veces cierran pulsando el aspa directamente. Aparece una compra y a continuación una anulación con un intervalo de menos de un minuto: Normalmente este tipo de error es debido a que la comunicación online que el comercio tiene activada ha fallado y el comercio tiene activada la respuesta requerida. Cuando no se recibe respuesta por parte del comercio al invocar a la url de la comunicación online se procede a la anulación de la operación. Revise que la comunicación online funciona correctamente. No se produce comunicacion on-line para las operaciones que se hacen desde la consola. La operación ha finalizado correctamente pero no se ha realizado la comunicación on-line 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. ¿Qué tengo que hacer para pasar de pruebas a producción? Pasar de pruebas a real es tan sencillo como cambiar el valor de la clave de cifrado y la dirección del actión a donde envías los datos, pasando de clave_encriptacion = 1111111





78

http://tpv.ceca.es:8000/cgi-bin/tpv a entorno seguro clave_encriptacion = 2222222 https://pgw.ceca.es/cgi-bin/tpv El entorno de pruebas sigue activo aunque el comercio pase a real. En resumen, el paso a real puedes hacerlo cuando quieras, aunque conviene avisar a tu Caja de la entrada en producción para estar pendiente de posibles incidencias en medios de pago. ¿Existen tarjetas para probar en el entorno de producción? Existen tarjetas de prueba para el entorno de desarrollo. Para el entorno de producción son necesarias tarjetas de verdad y que soporten autenticación si el comercio es seguro. ¿Cómo puedo acceder a la consola de administración del comercio? Consultar el anexo VII Consola de administración TPV Virtual para Comercios. Por defecto el usuario y la password son el merchantid del comercio. La pantalla de identificación tiene un tiempo máximo para introducir usuario y password. Si se produce un error al identificarte debe cerrar y volver a abrir el navegador




http://tpv.ceca.es:8000/cgi-bin/tpv

https://pgw.ceca.es/cgi-bin/tpv


79

RECOMENDACIONES.

- Desde el TPV virtual siempre recomendamos que en los procesos de actualización de tablas, bases de datos o actualización de registros por parte del comercio con el fin de confirmar inmediatamente la terminación de una transacción se realice utilizando la llamada �Comunicación on line� que se explica en este mismo manual y nunca a través de las paginas y el proceso de navegación del cliente.

- En este proceso de Comunicación on line es conveniente o Verificar que el valor de referencia no está vacío. o Recalcular la firma para comprobar el origen y valor de la referencia. o Verificar que número de operación e importe se corresponden con una operación

pendiente de pago. o Verificar dirección IP de procedencia o Y en los casos posibles utilizar una dirección HTTPS.

- Se recomienda la generación del número de operación de forma que estos no se repitan. En caso de ser un número cíclico que su periodo de repetición sea tan grande que sea imposible completar un ciclo.

- Administración de password y acceso al comercio.

o Recomendamos enérgicamente que el password de acceso a los entornos de administración se cambie la primera vez de uso y que en este cambio se indique una password mayor de 8 dígitos, que sea alfanumérica con al menos 3 dígitos numéricos y de una complejidad relativa. También puede incorporar distinción entre mayúsculas y minúsculas.

Recomendaciones de la Agencia de Protección de Datos. La Agencia Española de protección de datos, entidad cuya misión es velar por el cumplimiento de la legislación sobre protección de datos y controlar su aplicación, en especial en lo relativo a los derechos de información, acceso, rectificación, oposición y cancelación de datos, edita unas interesantes recomendaciones para el sector de comercio electrónico que es conveniente conocer, estudiar y aplicar. Desde el TPV virtual aconsejamos que el comercio siga todas las recomendaciones que esta entidad dicta. Desde la WEB

https://www.agpd.es/ se puede acceder a esta y otras documentaciones. En la sección �Protegiendo sus datos� � �Recomendaciones� puede encontrar estas recomendaciones.

https://www.agpd.es/index.php?idSeccion=75 La documentación PDF puede encontrarse en*:

https://www.agpd.es/upload/recomendaciones_comercio_electronico_pdf.pdf (* Esta dirección podría variar, se recomienda el acceso desde la pagina principal)




https://www.agpd.es/

https://www.agpd.es/index.php?idSeccion=75

https://www.agpd.es/upload/recomendaciones_comercio_electronico_pdf.pdf


Document

Documents

Transcript of Document