Documentos de Académico
Documentos de Profesional
Documentos de Cultura
0
MANUAL DE IMPLEMENTACION PARA COMERCIOS
1
CONTENIDO
CONTENIDO ....................................................................................................................................... 2
1.- INTRODUCCIÓN: .......................................................................................................................... 3
Características más importantes: .................................................................................................... 3
2.- POR DÓNDE EMPEZAR: .............................................................................................................. 5
3.- TIPOS DE COMERCIOS: .............................................................................................................. 6
Estándar/Inseguro: .......................................................................................................................... 6
Seguro: ............................................................................................................................................ 6
Mixto: ............................................................................................................................................... 6
4.- ESCENARIOS DE PAGOS:........................................................................................................... 8
Pago en comercio electrónico Estándar/no seguro:........................................................................ 8
Pago en comercio electrónico Seguro (3D-Secure) ...................................................................... 10
5.- CÁLCULO DE LA FIRMA............................................................................................................ 12
6.- PROGRAMACIÓN A REALIZAR EN EL SERVIDOR DE COMERCIO...................................... 14
6.1.- Compatibilidad con versiones anteriores .............................................................................. 15
6.2 Ejemplos de formularios .......................................................................................................... 16
Ejemplo de llamada en la que los datos de tarjeta son solicitados por el TPV ......................... 16
Ejemplo de llamada en la que los datos de tarjeta son solicitados por el comercio.................. 17
6.3 Direcciones de llamada ........................................................................................................... 18
7.- PÁGINAS DE PAGO.................................................................................................................... 19
7.1.- Características de las páginas de pago propias del TPV ..................................................... 19
8.- COMUNICACIÓN ON-LINE ........................................................................................................ 20
Comunicación online con respuesta requerida: ............................................................................ 21
8.1.- Ver y modificar la configuración online actual de su comercio ............................................. 21
9.- CONSULTA ONLINE DE OPERACIONES REALIZADAS: ......................................................... 23
11.- ANULACIÓN DE OPERACIONES............................................................................................. 25
Anulación parcial desde WEB del Comercio. ................................................................................ 27
12.- CONSOLA DE ADMINISTRACIÓN TPV VIRTUAL PARA COMERCIOS................................. 28
Acceso ........................................................................................................................................... 28
Cambio de entorno ........................................................................................................................ 28
Día a Día –Comparar fechas ......................................................................................................... 28
Día a Día –Ver informes diarios..................................................................................................... 29
Listado de operaciones.................................................................................................................. 29
Detalle de una operación............................................................................................................... 30
Anulación de una operación .......................................................................................................... 31
Anulación parcial de una operación .............................................................................................. 31
Pagos periódicos ........................................................................................................................... 31
Operaciones de un pago periódico................................................................................................ 32
Pagos de un pago periódico .......................................................................................................... 33
Pagos directos ............................................................................................................................... 34
Pagos por email............................................................................................................................. 35
Configuración – Datos del comercio.............................................................................................. 36
Configuración – Filtros de compra................................................................................................. 37
Usuarios y perfiles ......................................................................................................................... 38
13.- DIRECCIONES DE SOPORTE TPV ......................................................................................... 39
ANEXO V. TARJETAS DE PRUEBAS.............................................................................................. 40
ANEXO VI. PAGO SEGURO 3D-SECURE. ..................................................................................... 41
ANEXO VIII: TRATAMIENTO DE ERRORES.................................................................................. 45
ANEXO IX: PETICIÓN DE CVV2/CVC2 ........................................................................................... 48
ANEXO X. OPERATORIA MULTIMONEDA ..................................................................................... 49
ANEXO XI: GESTOR DE OPERACIONES....................................................................................... 52
ANEXO XII: OPERATORIA AMEX (AMERICAN EXPRESS)........................................................... 55
PREGUNTAS FRECUENTES........................................................................................................... 58
RECOMENDACIONES. .................................................................................................................... 60
CONTROL DE VERSIONES:............................................................................................................ 61
2
1.- INTRODUCCIÓN:
En este documento se describen las características de la versión 5.0 del TPV virtual
ofrecido por CECA. Un TPV es un software que se implementa en los SERVIDORES WEB DEL
COMERCIO y que permite realizar pagos securizados mediante una tarjeta de crédito/débito en
internet.
Esta nueva versión es totalmente compatible con las versiones anteriores, por lo que
aquellos COMERCIOS que ya estén utilizando el TPV virtual de CECA, podrán continuar
haciéndolo sin necesidad de realizar ningún cambio en su programación, a no ser obviamente, que
quieran incorporar alguna de las nuevas características.
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.
Uso protocolo SSL.- El CLIENTE sólo necesita disponer de un navegador WEB que
soporte SSL 3.0 con claves de cifrado de 128 bits (prácticamente todas las versiones
actuales de navegadores existentes en el mercado cumplen este requisito) y el
COMERCIO sólo requiere estar creado y autorizado en las tablas del TPV virtual de
CECA.
3
Autentificación del COMERCIO e Integridad de los datos enviados entre el
CLIENTE/COMERCIO y el TPV virtual.
Comunicaciones Firmadas Todas las comunicaciones hacia el TPV virtual van
protegidas por una firma electrónica que es calculada e insertada por el COMERCIO en
base a sus propios datos (MerchantID, AcquirerBIN y TerminalID) y a los datos de la
operación (Número de operación, Importe, Tipo de Moneda, Exponente). La firma
electrónica es recalculada por el TPV virtual y comparada con la firma electrónica
recibida antes de proceder a aceptar cualquier pago. De esta forma se evita que un
tercero pueda manipular cualquier dato entre el envío de los datos desde el comercio
hasta el TPV virtual.
4
2.- POR DÓNDE EMPEZAR:
A continuación se muestran una serie de pasos a realizar para implementar un TPV en la WEB del
comercio. Estos pasos son orientativos, y cada comercio puede adaptarlos según su forma de
trabajar.
1. Cómo se decía en el punto primero de este manual, la persona que vaya a implementar el TPV
deberá tener los conocimientos de programación necesarios.
2. El comercio deberá tener un espacio web donde albergar la tienda, ya sea a través de sus
propios recursos o contratando un hosting con alguna empresa que permita la instalación de
TPVs. En el apartado 5 Rutina del cálculo de la firma - Formas habituales de Uso y requisito
del hosting se describen los requisitos que debe tener.
3. Tener instalada alguna aplicación de comercio electrónico (página web de la tienda) que
permita al cliente poder seleccionar los productos que desea comprar
5. Una vez que el cliente ha seleccionado los productos y va a proceder al pago, se debe calcular
una firma a partir de una serie de campos. Para calcular dicha firma el comercio debe utilizar la
clave de cifrado recibida. Una vez calculada la firma desde el script (php, perl, etc) ésta será
enviada a CECA junto con e resto de campos necesarios, bien al entorno de pruebas bien al
entorno de producción (Ver Apartado 6.2- Programación a realizar en el servidor del
comercio - Ejemplos de formulario)
6. En esta nueva versión ya no es necesario personalizar las páginas de pago como en versiones
anteriores, ya que el propio TPV las incorpora de serie cumpliendo con una serie de requisitos
explicados en el apartado 7 del manual.
7. Por último y si de desea tener confirmación en la WEB del comercio de las operaciones
realizadas se procederá a configurar la comunicación on-line. Para ello el comercio tendrá que
realizar el desarrollo de un proceso con esa función e indicar a CECA su URL. (Ver apartado 8
Comunicación on-line)
5
3.- TIPOS DE COMERCIOS:
Existen varios tipos de comercios definidos dentro de la solución TPV de las Cajas de Ahorros. El
desarrollo WEB para un comercio es el mismo para todos los casos, sólo depende del acuerdo que
se tenga con la entidad. El cambio de un tipo a otro es transparente para el comercio, pero antes
se debe tener claro lo que significa cada tipo.
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 (Limite a securizar), que puede consultar y
modificar desde la administración del comercio. En este caso en las operaciones seguras el
comercio tiene garantía de pago y en las no seguras el responsable es el propio comercio.
Que el comercio sea mixto no quiere decir que las operaciones con importes inferiores a
importe indicado se procesen de modo inseguro. El limite securizado no funciona de ese
modo. Si una tarjeta admite autenticación, el proceso de autenticación se inicia
independientemente del importe de la operación. El TPV si el comercio es seguro o mixto
interroga a Visa/MasterCard para saber si una tarjeta admite autenticación. Si la tarjeta admite
auntenticación en todos los casos (no importa el importe) se presenta la pagina de
autenticación de la entidad que corresponda.
Una vez se presenta la pagina del banco para iniciar el proceso de autenticación hay dos
6
opciones.
-. El banco que corresponda no permite continuar sin autentificarte
-. El banco que corresponda permite continuar temporalmente sin autentificarte o te pide
el CVC2 o un dato de seguridad inferior para que temporalmente puedas comprar en comercio
seguro
El TPV no influye para nada en este proceso, es decisión única del banco emisor que permita
a sus clientes continuar o no continuar, es decir, comprar o no comprar en comercio seguro sin
autenticarse.
7
4.- ESCENARIOS DE PAGOS:
1 Comercio
Cliente
7 8
10 4 3 2
TPV Virtual
5 6 9
Pasarela SET/SEP
8
1. Una vez que el cliente ha finalizado de confeccionar el pedido, y solicita pagar
mediante tarjeta de crédito/débito, el comercio le presenta la página de pago en un
formulario HTML en el que no se requieren los datos de la tarjeta de crédito/débito.
3. Si los datos recibidos son correctos, el TPV virtual le presenta al cliente una página
HTML con un formulario que contiene los mismos campos ocultos recibidos en el punto
2, en el que se requieren los datos de la tarjeta de crédito/débito. Esta página podrá
ser personalizada por Comercio ó Caja Merchant.
5. Si los datos recibidos son correctos, el TPV virtual solicita el pago a la pasarela
SET/SEP.
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.
Existe la posibilidad de que los datos de la tarjeta sean solicitados por el comercio. En este caso el
comercio debe justificar la necesidad de operar de esta forma y tener la aprobación por parte de la
entidad bancaria. Además el comercio deberá auditar los procesos de seguridad necesarios
definidos por VISA y Mastercard que permita custodiar los datos de la tarjeta de forma totalmente
segura. El comercio podrá recibir una auditoria para verificar que dichos procesos de seguridad se
están realizando.
9
Pago en comercio electrónico Seguro (3D-Secure)
Comercio
Cliente
5 4 3 2
7 13 14
6
16
10 12 15
7 8
11
BANK Server
Pasarela SET/SEP
10
Siendo:
1. Una vez que el cliente ha finalizado de confeccionar el pedido en una tienda que presente los
logotipos "Verified by Visa" o "MasterCard© Secure Code", seleccionados los productos y
solicitado el pago mediante tarjeta de crédito / débito, el comercio le presenta la página de
pago en un formulario HTML en el que no se requieren los datos de la tarjeta de crédito /
débito.
2. Al pulsar el cliente el botón Aceptar, la información es enviada al TPV virtual instalado en
CECA.
3. Si los datos recibidos son correctos, el TPV virtual le presenta al cliente una página HTML con
un formulario que contiene los mismos campos ocultos recibidos en el punto 2, en el que se
requieren los datos de la tarjeta de crédito/débito. Esta página podrá ser personalizada por
Comercio ó Caja Merchant.
4. El cliente rellena el formulario y al pulsar el botón Aceptar, la información es enviada al TPV
virtual instalado en CECA.
5. El sistema detecta que su tarjeta está activada en Comercio Electrónico Seguro, e inicia la
autenticación de su titular.
6. Esta autenticación del titular se realizará a través de una pequeña pantalla que en ese
momento se abre. Esta securización se podrá realizar por varios caminos, a través de Vini, por
Teléfono móvil, contra banca electrónica, etc.. Este mecanismo es propio del emisor de la
tarjeta y por tanto difiere bastante en función de quien es el emisor de la tarjeta.
7. El cliente debe identificarse mediante el mecanismo facilitado por su entidad y por tanto
autorizar la operación.
8. Si se confirma la identidad del usuario, el emisor procede a autorizar la operación. La ventana
emergente se cerrará y continuará la operación adelante.
9. El emisor autoriza la operación emitiendo una firma única para esta operación, envía la
operación al TPV.
10. El TPV acepta la petición, comprueba datos e identifica la operación como securizada y lo
remite al emisor.
11. Tras recibir el mensaje de petición de autorización, el emisor validará que el AAV de la petición
de autorización es igual al generado originalmente y determinará si ese AAV fue usado
anteriormente. De ser así, se deniega la operación.
12. La pasarela SET/SEP devuelve el resultado de la operación al TPV virtual.
13. Si la operación se ha efectuado correctamente, el TPV virtual informa al comercio.
14. El Comercio comprueba y registra la operación y comunica nuevamente el resultado al TPV
virtual.
15. Si en el paso anterior el TPV virtual no consigue comunicar la operación al Comercio o éste
detecta algún problema, el TPV virtual solicita a la Pasarela SET/SEP que anule la operación.
16. El TPV virtual informa finalmente al cliente del resultado de la operación.
NOTA:
Como se verá más adelante, los pasos 13,14 y 15 son opcionales por comercio. Este caso se corresponde a
un caso con comunicación on line y respuesta requerida activada.
En este caso el comercio nunca conocerá el número de tarjeta empleado en la transacción ya que este dato
no se envía ni en los procesos de comunicación on line ni aparece reflejado en la consulta de operaciones.
Existe la posibilidad de que los datos de la tarjeta sean solicitados por el comercio. En este caso el comercio
debe justificar la necesidad de operar de esta forma y tener la aprobación por parte de la entidad bancaria.
Además el comercio deberá auditar los procesos de seguridad necesarios definidos por VISA y Mastercard
que permita custodiar los datos de la tarjeta de forma totalmente segura. El comercio podrá recibir una
auditoria para verificar que dichos procesos de seguridad se están realizando.
11
5.- CÁLCULO DE LA FIRMA
Uno de los parámetros que recibe TPV en su llamada es el parámetro firma. Dicho parámetro es
utilizado para autenticar la llamada realizada y comprobar que su contenido no ha sido alterado por
terceros.
El algoritmo utilizado para calcular la Firma es: Secure Hashing Standard FIPS PUB 180-1
[http://www.itl.nist.gov/fipspubs/fip180-1.htm], comúnmente conocido como SHA-1. El resultado
produce una salida de 160 bits (20 bytes) que se debe codificar en HEXADECIMAL con letras
minúsculas. La mayoría de los algoritmos suelen devolver 5 bloques de 4 bytes cada uno, para
posteriormente convertirlo en una cadena a enviar en un formulario HTML. Dicha cadena se debe
convertir a hexadecimal y rellenar a ceros por la izquierda en caso necesario. La mayoria de los
lenguajes de programación tienen una segunda función que realiza esta operacióin.
Para aclarar un poco lo explicado en el párrafo anterior vamos a utilizar el siguiente ejemplo:
Cadena:
SHA1("11439044111950028000055405200000003221__0.67530300126148883300000000000197
82120035304709122214340106007000")
Longitud: 106
Resultado: 62753a72 498191fd 09175074 7b8750bc 6cb06e8f
En el tercer bloque, algunos algoritmos pueden devolver 9175074 , es necesario que sean 8
caracteres, por tanto será 09175074 .
SHA1("") = da39a3ee5e6b4b0d3255bfef95601890afd80709
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)
Clave_encriptacion+MerchantID+AcquirerBIN+TerminalID+Num_operacion+Importe+Tipo
Moneda+Exponente+Referencia+Cifrado+URL_OK+URL_NOK
Ejemplo:
MerchantID: 111950028
AcquirerBIN: 0000554052
TerminalID: 00000003
Num_operacion: 123
12
Importe: 500
TipoMoneda: 978
Exponente: 2
Referencia:
URL_OK: http://www.ceca.es
URL_NOK: http://www.ceca.es
-->Cadena_sha1:
998888881119500280000554052000000031235009782SHA1http://www.ceca.eshttp://www.ceca.e
s
-->Longitud:[85]
-->Firma_calculada: 15ba153908476895d9edd75ff23b207707d2c885
Para la comunicación on line, el proceso es el mismo. La firma enviada por el TPV es con los
campos actuales
Clave_encriptacion+MerchantID+AcquirerBIN+TerminalID+Num_operacion+Importe+Tipo
Moneda+Exponente+Referencia
En el caso de que el comercio decida hacer la programación para poder realizar anulaciones desde
su página web, la cadena de la firma con sha-1 en las anulaciones es como la de la comunicación
on line expuesta anteriormente.
13
6.- PROGRAMACIÓN A REALIZAR EN EL SERVIDOR DE
COMERCIO
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:
14
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 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.
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.
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.
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.
1.- Español 2.- Catalán 3.- Euskera 4.- Gallego 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.
15
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>
Obviamente, la aplicación deberá sustituir los literales de los campos VALUE que
comienzan y terminan con ## por los valores adecuados.
16
Ejemplo de llamada en la que los datos de tarjeta son solicitados por el comercio
<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
17
Importante: Esta forma de funcionamiento debe contar con la aprobación por parte
de la entidad bancaria, por defecto no está permitida. El comercio debe justificar la
necesidad de esta forma de operar así como auditar los procesos de seguridad
necesarios para solicitar datos bancarios desde su servidor.
Conviene también citar en este punto, que existen dos entornos de TPV virtual instalados en
CECA, siendo sus URLs correspondientes:
Estos serán los únicos valores válidos en el campo ACTION de los formularios descritos
anteriormente.
18
7.- PÁGINAS DE PAGO
Por cada comercio, el TPV virtual maneja un juego de páginas compuesto por:
La mayoría de las entidades dispone de un juego de páginas que todos sus comercios deben
utilizar, algunas incorporan un logo del comercio y no permiten utilizar paginas propias. Antes
de iniciar cualquier desarrollo es importante que contacte con su entidad o con
soporte.tpv@ceca.es para saber la política de su entidad al respecto. En el caso donde se
permita la personalización de las páginas se enviará al comercio unas plantillas sobre las que
añadir el diseño grafico
En el caso de que un comercio necesite utilizar unas páginas distintas de las de por defecto
deberá ponerse en contacto con soporte.tpv@ceca.es donde se le dará las instrucciones
necesarias para su personalización.
19
8.- COMUNICACIÓN ON-LINE
La comunicación on-line es utilizada por los comercios que necesita que las operaciones de
COMPRA realizadas por sus clientes le sean comunicadas en el momento de producirse. Consiste
en la creación de un proceso por parte del comercio al cual el TPV invocará cuando se haya tenido
la aceptación de la operación por parte de la entidad emisora de la tarjeta del cliente. Dicha
llamada podrá ser realizada por HTTP o HTTPS y se añadirá los siguientes campos para que el
comercio pueda identificar la operación:
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.….
20
Comunicación online con respuesta requerida:
En el caso que nos ocupa, en el que el comercio solicite una comunicación ON-LINE de las
operaciones de compra realizadas por sus clientes, se contemplan además dos posibilidades:
No se requiere una respuesta del comercio. En este caso, una vez realizado el pago, el
TPV virtual de CECA intentará comunicar la operación al comercio, pero dará por
realizada correctamente la operación aunque dicha comunicación no sea posible. Es
más, ni siquiera esperará recibir una respuesta desde el comercio.
Se requiere una respuesta del comercio. En este caso, si una vez realizado el pago, el
programa no consigue comunicar la operación al comercio ó detecta a partir de la
respuesta recibida que algo no ha ido bien, anulará la operación y la dará como
errónea al cliente.
Para que el programa sea capaz de discernir a partir de la respuesta recibida desde el
Comercio si todo ha funcionado correctamente ó si se ha producido algún error, es necesario que
en la respuesta generada por el CGI del comercio aparezca el texto $*$OKY$*$ sólo cuando
todo vaya bien, de modo similar a como figura en el siguiente ejemplo:
<HTML>
<HEAD>
<TITLE>Respuesta correcta a la comunicación ON-LINE</TITLE>
</HEAD>
<BODY>
$*$OKY$*$
</BODY>
</HTML>
21
Esquema del proceso
Se envía formulario a la
dirección especificada
Se presenta la Se envía formulario a la
pagina OK dirección especificada
Se va a la URL_OK
Incluye el string OKY No responde o no
Se presenta la incluye el string OKY
pagina OK
Se presenta la
pagina OK
Se va a la URL_OK Se presenta la
pagina Error atrás con
ERROR en la comunicación
Se va a la URL_OK on line.
22
9.- CONSULTA ONLINE DE OPERACIONES REALIZADAS:
Con el fin de que los Comercios puedan consultar y/o anular las operaciones efectuadas por sus
clientes, CECA ha instalado en uno de sus servidores WEB seguros, una aplicación accesible
desde cualquier navegador, que permite a los comercios realizar un seguimiento online de su
actividad. Para mayor información sobre esta herramienta consultar el apartado “Consola de
administración del comercio” de este manual.
23
10.- COMUNICACIÓN BATCH DE LAS OPERACIONES
REALIZADAS
Tanto si el Comercio utiliza ó no la facilidad de comunicación ON-LINE de las operaciones de
compra realizada por sus clientes, tal y como se describió en el apartado compras en INTERNET,
CECA podrá generar y enviar al Comercio al final de cada día, un fichero que contendrá el listado
de las operaciones efectuadas durante el mismo.
Por motivos de seguridad, este fichero irá cifrado. Para descifrarlo será necesario hacer uso de las
herramientas proporcionadas por CECA al Comercio.
Para el envío de este fichero, el Comercio podrá optar por uno de los siguientes sistemas:
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:
24
11.- ANULACIÓN DE OPERACIONES
Los campos que debe contener este formulario son los siguientes:
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:
25
Si va relleno, las páginas HTML mostradas por el CGI son:
Obviamente, en este caso las páginas HTML deben haber sido previamente proporcionadas por
el Comercio.
El campo ACTION del formulario apuntará a la URL de un Servidor WEB de CECA correspondiente
al CGI que tratará los datos del formulario, y que podrá ser una de las siguientes:
https://pgw.ceca.es/cgi-bin/tpvanular 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>
26
Obviamente, la aplicación deberá sustituir los literales de los campos VALUE que
comienzan y terminan con ## por los valores adecuados.
De modo similar a como ocurre con las operaciones de compra, el comercio puede requerir que las
operaciones de ANULACION realizadas le sean comunicadas en el momento de producirse. En
este caso, la comunicación se realizará mediante protocolo HTTP ó HTTPS, por lo que el Comercio
deberá desarrollar e instalar un proceso, comunicando a CECA la URL (incluyendo protocolo) del
mismo. Este CGI será invocado con los siguientes parámetros:
La funcionalidad de este proceso será la que determine el comercio, pero principalmente consistirá
en actualizar sus bases de datos internas.
27
12.- CONSOLA DE ADMINISTRACIÓN TPV VIRTUAL PARA
COMERCIOS
Desde este entorno de administración es posible tener acceso a los informes sobre
operaciones del comercios, realizar búsqueda de operaciones, anulaciones y establecer distintos
filtros de compra, modificación de parámetros, …
Acceso
La dirección establecida para el acceso a la consola de administración del TPV virtual es:
https://pgw.ceca.es/xxx
El usuario y password de acceso son los mismos que para la anterior administración y en caso de
no tenerla serán proporcionados en el correo de bienvenida recibido por el comercio.
Cambio de entorno
Existen dos entornos en los que se está ejecutando el TPV Virtual y ambos son autónomos. Estos
entornos son pruebas y producción. Desde la consola podremos cambiar a cada uno de ellos
mediante el enlace cambiar a pruebas o a real que aparece en la parte superior de la pantalla.
Para cada uno de ellos cambian los colores de la consola para que visualmente se pueda distinguir
en cuál de ellos estamos.
Una compara OK es aquella que ha sido procesada correctamente, NOK la que se ha intentado
procesar pero ha sido denegado y filtrada es aquella que no se ha llegado a procesar por cumplir
alguno de los filtros definidos por la caja y/o comercio.
A la derecha de cada gráfico existen unos porcentajes que serán visibles en el caso de que no
estemos filtrando por alguno de los parámetros antes mencionados y nos indicará el porcentaje de
operaciones anuladas y el porcentaje de operaciones NOK con respecto al total.
Además debajo de cada gráfico aparece un sumatorio con el número total de operaciones por día
que estamos comparando.
28
Día a Día –Ver informes diarios
Permite sacar un informe de las operaciones procesadas durante un periodo.
Listado de operaciones
Listado de las operaciones realizadas durante un periodo determinado. La aplicación nos permite
hacer una búsqueda en base a unos parámetros básicos como son Fecha de inicio, finalización,
tipo (compra, anulación), resultado (OK,NOK, filtrada) y canales (Internet, pago periódico, pago
directo, email, tpv-blanco)
29
En el caso de que los parámetros anteriores no sean necesarios para localizar una operación
podemos pinchar sobre el botón Más opciones y nos permitirá también buscar por un rango de
importe, número de tarjeta, número de operación y número de autorización. En el caso del
número de tarjeta este campo admite el carácter comodín % de tal manera que si queremos buscar
todas las tarjetas que empiecen por 7854 pondremos en dicho campo el valor 7854%. El carácter
comodín podemos ponerlo en cualquier parte del campo, es decir si conocemos los primeros
dígitos de la tarjeta y los últimos podremos utilizar el valor 9999%99 y nos dará como resultado
todas las tarjetas que comiencen por 9999 y que además terminen en 99.
Por cada una de las operaciones que aparecen en el listado podremos consultar su detalle y
proceder a su anulación.
30
Anulación de una operación
Para anular una operación que ha sido realizada correctamente tendremos que buscarla en el
listado de operaciones y una vez localizada tenemos dos alternativas.
1. Pinchar en el enlace más detalle y pulsar el botón anular operación
2. Pinchar en la X que aparece al final de la operación
Por cualquiera de estos caminos se nos solicitará una confirmación antes de proceder a su
anulación.
Destacar que sólo se puede realizar una única anulación parcial por operación, es decir si una
operación es de 100 euros y realizamos una anulación parcial de 75 euros, el resto no podrá ser
anulado por este procedimiento, teniéndose que dirigir a su entidad para hacer el abono
correspondiente al cliente.
No todos los comercios disponen de esta opción, por lo que en caso de no aparecer deberá
ponerse en contacto con su entidad.
Pagos periódicos
Consulta de operaciones y pagos periódicos realizadas entre dos fechas determinadas. No todos
los comercios disponen de esta opción, por lo que en caso de no aparecer deberá ponerse en
contacto con su entidad.
31
Dentro de este apartado tenemos que distinguir entre dos conceptos:
Operación: Es una operación fraccionada en varios pagos. Por ejemplo la suscripción
anual a una revista con un pago mensual de 10 euros. La operación es de 120 euros
Pago: Es cada uno de las pagos que forman una operación. En el ejemplo anterior
tendremos un total de 12 pagos.
Desde esta opción podremos consultar todas las operaciones realizadas de este tipo. La aplicación
nos permite hacer una búsqueda en base a unos parámetros básicos como son rango de fechas.
En el caso de que los parámetros anteriores no sean necesarios para localizar una operación
podemos pinchar sobre el botón Más opciones y nos permitirá también buscar por un rango de
importe, número de tarjeta, número de pagos y referencia de la operación.
Para cada operación, la aplicación nos permite realizar alguna de las siguientes acciones:
Acceder a los pagos de los que está compuesta, para ello pulsaremos sobre el icono que
aparece en la columna de pagos
Consultar los detalles de la operación. Pinchando el botón más que aparece por cada
operación
Anular la operación. Pinchando el icono de anular X que aparece al final de cada
operación. En el caso de que la operación ya esté anulada, este icono no aparecerá
32
Pagos de un pago periódico
Un pago periódico es una parte de una operación periódica.
Desde esta opción podremos consultar todas las operaciones realizadas de este tipo. La aplicación
nos permite hacer una búsqueda en base a unos parámetros básicos como son rango de fechas y
estado.
En el caso de que los parámetros anteriores no sean necesarios para localizar un pago podemos
pinchar sobre el botón Más opciones y nos permitirá también buscar por un rango de importe,
número de tarjeta, referencia de pago y referencia de la operación.
Los posibles estados que puede tener un pago son los siguientes:
Anulado. Pago que na sido anulado una vez se ha procesado con éxito
Cancelado. Pago que ha sido cancelado antes de llegar a su fecha de pago.
Cancelado con error. Pago cuyo estado era error y al procesarlo de nuevo ha vuelto a
fallar. El original aparece con este estado y aparece un registro nuevo con el estado de
error
Cancelado por modificación con error. Pago que ha dado un error y ha sido modificado
para volverse a procesar. El original aparece con este estado y aparece un registro nuevo
como pendiente
Cancelado por modificación. Pago que ha sido modificado antes de llegar a su fecha de
pago. El original aparece con este estado y aparece un registro nuevo como pendiente
En curso. Pago que se está realizando en este momento.
Error. Pago que ha sido procesado y su resultado ha sido error.
Pagado. Pago que ha sido procesado de forma correcta.
Pendiente. Pago que está pendiente de procesar por no haber llegado la fecha de pago.
Por cada pago que nos aparece en la consulta podremos realizas las siguientes acciones
dependiendo de su estado
Consultar los detalles del pago
Anular
Reprocesar la operación
Modificar
33
Pagos directos
Un pago directo es una operación que se genera íntegramente por el comercio desde la consola de
Administración sin utilizar las páginas web del comercio. No todos los comercios disponen de esta
opción, por lo que en caso de no aparecer deberá ponerse en contacto con su entidad.
Esta opción solo tiene sentido si el cliente ha facilitado los datos de su tarjeta al comercio y el tipo
de comercio es no seguro, ya que en caso contrario saltaría las pantallas de autenticación del
cliente, siendo estos desconocidos por el comercio.
En el caso de que el comercio no disponga de los datos de pago deberá utilizar el pago por email
explicado más adelante.
34
Pagos por email
Un pago por email es una operación que es dada de alta por el comercio y que se envía por email
al cliente, para que la complete introduciendo los datos de su tarjeta. No todos los comercios
disponen de esta opción, por lo que en caso de no aparecer deberá ponerse en contacto con su
entidad.
Una vez que el comercio ha realizado la operación se enviará un email al cliente con las
instrucciones necesarias para terminar la compra. Se podrá realizar un seguimiento de la misma a
través de esta consola. Los posibles estados que puede tener una operación por email son los
siguientes:
Enviado. La operación ha sido enviada al cliente y está a la espera de su terminación.
Completado OK. La operación ha sido enviada al cliente y éste ha introducido los datos de
pago correspondiente siendo su resultado satisfactorio.
Completado NOK. La operación ha sido enviada al cliente y éste ha introducido los datos
de pago correspondiente siendo su resultado error.
Cancelado. La operación ha sido enviada al cliente, pero el comercio ha decidido
cancelarla antes de que el cliente haya intentado terminarla. En el caso de que el cliente ya
haya terminado la operación esta no podrá ser cancelada. Para ello deberá dirigirse al
listado de operaciones y anularla como se ha explicado en el punto anterior de este
manual.
Por cada uno de los pagos que aparece en la consulta de pagos por email, dependiendo del
estado en el que se encuentra, se podrá realizar las siguientes acciones:
Cancelar.
35
Configuración – Datos del comercio
Visualiza y modifica la configuración del comercio.
Otros datos del comercio. Se muestran otros tipos de datos relativos al comercio como son
la fecha de alta, su estado,..
Configuración del servicio. Indica el estado en que se encuentran las distintas opciones
que puede realizar un comercio dentro de su operatoria. Este estado no es modificable por
el usuario y en caso de querer cambiar alguno de ellos debe poner en contacto con su
Caja
36
Configuración – Filtros de compra
Un filtro es un control que se realiza antes de realizar una operación en el tpv. En el caso de que
se cumpla alguno de ellos, la operación no será procesada y aparecerá en la consulta de
operaciones como “filtrada”.
No todos los comercios tienen esta opción disponible, por lo que en caso de no aparecer y estar
interesado en ella deberá ponerse en contacto con su Caja para que se la habilite.
Aunque los filtros estén definidos, estos no serán efectivos hasta que estén activados. Para ello
existe al final de la página un botón que nos permite activarlos o desactivarlos según su estado
actual
Realizar con mucho cuidado cualquier modificación sobre alguno de estos parámetros.
37
Usuarios y perfiles
Consulta y administra los usuarios que tienen acceso a la consola del TPV. La consola de
administración del TPV-Virtual maneja tres tipos de roles de usuarios.
38
13.- DIRECCIONES DE SOPORTE TPV
Si necesitan resolver cualquier duda relacionada con este producto, deben inicialmente ponerse
siempre en contacto con su Caja de Ahorros.
Para cualquier problema relacionado con la implementación del TPV virtual en su comercio,
pueden ponerse en contacto con la dirección de correo electrónico soporte.tpv@ceca.es y teléfono
915965328.
Le recomendamos que antes de contactar con el soporte del TPV de las Cajas de
Ahorros consulte el apartado de preguntas frecuentes, ya que en la mayoría de los
casos en ese apartado se encuentra la solución al problema.
39
ANEXO V. TARJETAS DE PRUEBAS
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.
A partir del 1 de Abril de 2006 la nueva política de seguridad para comercio electrónico
obligará a los comercios que quieran solicitar los datos de tarjeta al cliente y que no quieran
delegar esta función en el TPV virtual, deban contar con una autorización expresa de la caja
correspondiente y cumplir las condiciones de seguridad y tratamiento de la información
impuestas por cada entidad.
A partir del 1 de diciembre de 2008 la nueva política de seguridad para comercio electrónico
obligará a que todas las operaciones de comercio electrónico sean tramitadas con el valor del
CVV2/CVC2 de la tarjeta. Más información en anexo IV Petición de CVV2/CVC2.
40
ANEXO VI. PAGO SEGURO 3D-SECURE.
En el siguiente Anexo se explicar el funcionamiento de un comercio que opera bajo la normativa
3D-Secure. Los comercios que utilicen este sistema podrán utilizar estos logos en su comercio,
además deben incluirlo en la página de pago personalizada.
41
Pantalla de activación de la identificación de cliente que presenta el TPV virtual.
42
43
44
ANEXO VIII: TRATAMIENTO DE ERRORES.
En las páginas de error se puede visualizar un código de error de rechazo de la operación,
ya bien sea debido a la propia aplicación o bien al rechazo por parte del emisor de la operación.
Este código viene recogido en el parámetro “COD_AUT”, que para las compras correctas siempre
será de valor “000” y para las anulaciones correctas “400” (“900” para anulaciones parciales). El
resto de valores representa un código de error.
Cod.
Autorización 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.
38 ERROR. Respuesta Errónea del Gestor de operaciones. [%d][%s].
45
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.
ERROR. Error en el proceso de Autentificación. No retroceda en el navegador. Debe volver al
46 comercio y reintentar el pago.
47 ERROR. Entidad no disponible. Inténtelo dentro de unos minutos
ERROR. Error en el proceso de Autentificación. Respuesta PAREQ no valida [%d]. No retroceda
48 en el navegador. Debe volver al comercio y reintentar el pago.
ERROR. Error en el proceso de Autentificación. Respuesta PAREQ de su entidad no valida:
49 %s,TXSTATUS
ERROR. Fallo en el proceso de Autentificación. Es necesario una identificación positiva para
50 finalizar el proceso de compra: %s,TXSTATUS
ERROR. Fallo en el proceso de Autentificación. El comercio no acepta pagos no seguros: %s.
51 Póngase en contacto con la entidad emisora de su tarjeta.,TXSTATUS
52 ERROR. En estos momentos no es posible iniciar un pago seguro
ERROR. Comercio seguro. Su tarjeta no admite autentificación y no puede operar en este
53 comercio [%s]. Póngase en contacto con la entidad emisora de su tarjeta.
ERROR. No es posible iniciar un pago seguro y el importe supera el máximo permitido (%f <=
54 %s). [Resultado: %s]
55 ERROR. En este momento no es posible iniciar un pago seguro. [Resultado: %s]
ERROR. No es posible iniciar un pago seguro y el importe supera el máximo permitido (%f <=
56 %s). [Resultado: %s]
ERROR. En este momento no es posible iniciar un pago seguro y el importe supera el máximo
57 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)
ERROR. El comercio no acepta pagos Visa no autentificados. Póngase en contacto con su
63 entidad para activar este tipo de pago.
ERROR. El comercio no acepta pagos MasterCard no autentificado. Póngase en contacto con su
64 entidad para activar este tipo de pago.
ERROR. El comercio no acepta pagos no autentificados. Póngase en contacto con su entidad
65 para activar este tipo de pago.
ERROR. Error de proceso. El comercio no acepta pagos no autentificados. Póngase en contacto
66 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).
ERROR. Respuesta Errónea del Gestor de operaciones. Operación anulada [%s].Gestor:
68 [%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)
106 Tarjeta no válida (reintentos de PIN)
46
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
47
ANEXO IX: PETICIÓN DE CVV2/CVC2
Las modificaciones a realizar por los comercios que requieran la validación del
CVV2/CVC2 son mínimas y muy sencillas. Distinguimos dos casos en función de si es el comercio
quien solicita los datos de la tarjeta o es el TPV virtual quien presenta la página de pago donde se
solicitan los datos.
1- .Comercios que solicitan los datos de Tarjeta y Caducidad desde su propio servidor de comercio
Simplemente deben añadir un campo más denominada CVV2 y enviarlo con el resto de
campos que actualmente envían al TPV virtual
<INPUT TYPE="text" NAME="CVV2" size=3 maxlength=3 >
2-.Comercios que solicitan los datos de Tarjeta y Caducidad desde el TPV virtual
Lo distintos comercios que quieran solicitar este campo deberán modificar el diseño de sus paginas
para añadir este campo. Los comercios que no dispongan de una copia de sus paginas alojadas en
nuestro servidor pueden solicitarla enviando un correo a soporte.tpv@ceca.es indicando en el
correo el número de comercio (MerchantID), se les enviará la copia actual para poder realizar las
modificaciones oportunas que consisten en añadir el campo CVV2.
Páginas de Ayuda a disposición de los comercios para saber que es el CVC2 e informar desde la
página de pago.
http://tpv.ceca.es:8000/admincomercios/ayuda_cvc2.html
https://pgw.ceca.es/admincomercios/ayuda_cvc2.html
Es importante señalar que el CVC2 se valida si tiene un valor no vacío, luego si el comercio quiere
exigir su validación debe asegurarse que el cliente rellena el campo.
48
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.
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
sin formatear.
49
a) Esquema de funcionamiento
En este caso se interpreta que el comercio desea realizar una operación de 37,50 Libras esterlinas
(código moneda 826). El TPV buscará 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.
Paso3
Paso1
TPV 18:00
Comercio
Paso2
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.
50
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.
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.
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 -. 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.
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.
51
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)
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
52
Estos son los nuevos campos
<INPUT NAME="Datos_operaciones" value="201009100000020001" size=20>
<INPUT NAME="Tipo_operacion" TYPE=text size=1 VALUE="A">
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”.
53
<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>
54
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: wthspain@aexp.com) 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.
55
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
puntos .
56
ANEXO XIII: Códigos de idioma
Códigos de idioma:
1.- Español 2.- Catalán 3.- Euskera 4.- Gallego 5.- Valenciano
6.- Inglés 7.- Francés 8.- Alemán 9.- Portugués 10.- Italiano
57
PREGUNTAS FRECUENTES.
La página que me aparecen para introducir el número de tarjeta está en blanco y sin ningún
formato
Ello Es debido a que no ha personalizado las páginas. Consulte el apartado 7 Personalización de
páginas de este manual
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.
58
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.
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.
59
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.
60
CONTROL DE VERSIONES:
01/12/2009 Versión 4.5
Revisión íntegra del manual
61