Protocolo de Conexión

Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Protocolo de Conexión
Versión 1.5 – Español
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 1 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Aviso Legal y Responsabilidades
El presente documento es un documento privado de propiedad de ClearONE. La marca ClearONE
está registrada en el proceso de patentar. Queda totalmente prohibido copiar, duplicar, escanear, etc.
todo o partes del presente documento sin el permiso por escrito de ClearONE.
El receptor acepta y declara haber comprendido el significado de la firma del Contrato de
Confidencialidad (NDA), proceso llevado a cabo junto con ClearONE previo a la entrega del presente
documento.
Este documento ha sido elaborado por el Dpto. de Desarrollo de ClearONE, y las personas
responsables son:
Arquímedes Palacios – Jefe de Desarrollo, [email protected].
Paul Zander – Director General, [email protected].
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 2 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Indice
1. ClearONE – Pasarela de Pagos con Servicio de TEF
1.1
1.2
Servicios Ofrecidos por ClearONE
Canales de Conexión
2. Operativa en el Punto de Venta
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
Venta
Devolución
Reserva de Fondos y Confirmación de Reserva
Recarga Telefónica
Anulaciones
Detalle de Operaciones y Datos Ultima Operación
Consulta de Totales
Fin de Día
Lectura de Tarjeta Privada
Venta TNA y Venta con DCC
Estado del Sistema
Selección de idioma
Captura de firma
3. Instalación y Configuración del Servicio
4. Como Integrar ClearONE en un Programa de Gestión
4.1
Un Ejemplo en C++
5. Formato de las Tramas de Datos
5.1
5.2
5.3
5.4
Tramas de Petición
Tramas de Respuesta
Trama de ACK
Diálogos Extendidos: Detalle Operaciones, venta TNA y
venta DCC.
6. Formato de los Tickets a Generar
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 3 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
1.ClearONE
ClearONE es una empresa que ofrece un servicio de Pasarela de Pagos a todos los actores en el
mercado con la necesidad de aceptar tarjetas de crédito y débito. Nuestro servicio de Pasarela ofrece
a los clientes distintas soluciones de conexión con los Centros Autorizadores. Nuestro trabajo consiste
en facilitar a nuestros clientes el hardware y software necesarios para que puedan conectar sus
puntos de venta con los centros autorizadores que operan en el territorio nacional. A través de dichas
conexiones, se canaliza principalmente el denominado servicio TEF (Transferencia Electrónica de
Fondos) y también se puede incorporar servicios de recarga telefónica y otros servicios. Con “puntos
de venta” en este contexto nos referimos a los sistemas de cobro en distintos sectores:
Supermercados, Hipermercados, Tiendas, Moda, Textil, Restaurantes, Bares, Hoteles, Discotecas,
Tiendas Especializadas, Farmacias, Gasolineras, Ayuntamientos, Recintos Feriales, Aviones, Trenes,
Autobuses, Cines, Ticketing, Parkings, Kioskos, Páginas WEB, etc., etc.
Tenemos líneas de conexión de alta capacidad que mantienen nuestros centros de servicio
permanentemente conectados con los Centros Autorizadores más importantes: Redsýs, CECA, AMEX,
etc. Fuimos la primera empresa española en certificar una conexión Price Servidores con Redsýs
(SERMEPA en aquel momento). Nuestro compromiso de continuo desarrollo en las distintas
modalidades en medios de pago así como nuestra dedicación a la seguridad avanzada de nuestros
sistemas nos permite ser una empresa líder en ofrecer soluciones EMV integradas.
1.1. Servicios Ofrecidos
Nuestro principal objetivo es dar al mercado la capacidad de integrar el cobro con tarjeta (el TEF) en
su aplicación de gestión del punto de venta. Esto le permite olvidarse del datafono del banco,
sustituyéndolo por un dispositivo integrado, un Pin-Pad que muchas veces es más ligero y versátil, en
el punto de venta. El proceso de cobro es más rápido porque se hace a través de ADSL y más fiable
porque no hay que teclear de forma manual el importe en un dispositivo externo: el importe a cobrar
es automáticamente transferido de la aplicación de venta (o de gestión) al Pin-Pad.
El hecho de no necesitar el datafono del banco tiene otras dos ventajas adicionales. En primer lugar es
posible negociar mejores precios y comisiones con el banco, ya que el banco se ahorra el coste del
datafono y el posterior mantenimiento del mismo. En segundo lugar permite al comercio trabajar con
varios bancos de forma simultánea (“multibanco”), utilizando un dispositivo único para todos. Así se
ahorra espacio en el punto de venta al eliminar los datafonos y se da al comercio mayor posibilidad de
negociación con los bancos. En una configuración multibanco, el comercio sigue teniendo la
posibilidad de elegir de forma manual el banco al que quiere enviar cada transacción. Pero lo habitual
es automatizar esa decisión para evitar errores, permitiendo que sea ClearONE quien determine el
banco al que debe ir cada transacción a partir de las condiciones indicadas por el cliente y sus bancos.
Además del cobro con tarjeta, hay otros servicios que funcionan de forma similar y pueden interesar a
muchos comercios. Uno de ellos es la venta de recargas telefónicas. ClearONE ha integrado dicho
servicio en su aplicación y lo ofrece junto con el servicio TEF a todos sus clientes. Otro servicio
disponible es el tratamiento de la venta “libre de impuesto” (Tax free) para personas procedentes de
países fuera de la Comunidad Europea. Consúltenos para más información.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 4 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
También ponemos a disposición de todos nuestros clientes el acceso a nuestra plataforma WEB de
informes, denominada WRP (Web Reporting Platform). Es una herramienta de consulta que funciona
en tiempo real permitiendo al usuario obtener multitud de informes, desde un sencillo listado de
transacciones para una sola tienda hasta complejos y elaborados informes que aportan a la dirección
comercial y/o financiera de las empresas la información que necesitan para sus decisiones
comerciales, de marketing y también para sus negociaciones con las entidades bancarias. Como
opción también existe la posibilidad de automatizar el traspaso de los datos transaccionales
directamente al sistema del cliente. De esta forma es posible integrar los datos en procesos ya
definidos para el cliente en cuestión.
Para dar acceso a todos estos servicios, ClearONE ha diseñado un módulo de software en el que se
acumula toda la experiencia de un equipo de personas que lleva más de 15 años trabajando en el
sector de los medios de pago y las comunicaciones. Dicho software se ha encapsulado en un servicio
Windows, compatible con cualquier plataforma a partir de Windows 98. El servicio se instala en cada
uno de los puntos de venta que se quiera conectar con la plataforma de ClearONE y la aplicación de
venta, o de gestión, se comunica con dicho servicio mediante sockets TCP/IP. Desde Junio de 2011
disponemos también de una versión Linux del ejecutable, con lo que podemos ofrecer el mismo
servicio a todos los clientes que trabajan en esta plataforma.
1.2. Canales de Conexión
El único requisito para poder conectar cualquier punto de venta (detallado anteriormente) con
ClearONE es que la conexión se haga mediante TCP/IP. Esto incluye conexiones por internet, GPRS,
3G, LMDS, etc.
La conexión más habitual es el ADSL. Sus principales ventajas son el bajo coste y el hecho de ser una
conexión permanente, evitando así el tiempo de conexión que es lo que hace tan lentos a los
habituales datafonos de los bancos. Utilizando este tipo de conexión el tiempo de proceso de una
transacción TEF suele estar en el orden de 1-2 segundos, frente a los 20-40 segundos que puede tardar
un datafono (si consigue conectar a la primera).
En cualquier caso, la posibilidad de conexión con ClearONE no es una lista cerrada. Nuestro interés
está en que los clientes se conecten a nuestra plataforma y por ello siempre estamos abiertos a
estudiar cualquier sistema de conexión que pueda beneficiar a nuestros clientes. Por ejemplo,
tenemos clientes que utilizan su red privada (VPN), creando puntos de acceso en las instalaciones de
ClearONE para aprovechar la fiabilidad y seguridad que este tipo de redes ofrece.
En la siguiente página mostramos un esquema funcional de nuestro servicio.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 5 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Esquema Funcional de la Pasarela de Pagos Cl ea r O N E
2. Operativa en el Punto de Venta
Como ya hemos dicho antes, nuestro software ofrece conexión con distintos servicios (TEF, recargas,
Tax free, etc.) y cada uno de ellos permite realizar distintos tipos de transacciones desde el punto de
venta. Dichas transacciones pueden resultar muy familiares para algunos usuarios, pero en otros casos
puede ser la primera vez que las vean. Por ello, describimos a continuación el funcionamiento lógico
de las mismas desde el punto de vista del punto de venta.
2.1. Venta
La operación de venta es la más habitual de todas. Lo que hace esta operación es solicitar al centro
autorizador que transfiera un importe determinado desde la cuenta asociada a la tarjeta del cliente
hasta la cuenta del comercio (de aquí viene el nombre de Transferencia Electrónica de Fondos).
El centro autorizador verifica la tarjeta, comprueba que tenga fondos, verifica los datos del comercio y
si todo es correcto, realiza el cargo en la cuenta del cliente y el abono en la cuenta del comercio. El
momento exacto en que se realizan el cargo y el abono depende de varios factores como el tipo de
tarjeta (crédito o débito) o la configuración del comercio (cierre automático o manual) pero para
entender el funcionamiento lógico del sistema, podemos afirmar que el cargo y el abono se hacen
simultáneamente en el momento en que se procesa la operación.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 6 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Para realizar esta operación, el programa de gestión del punto de venta manda al servicio de
ClearONE una petición con el importe, numero de ticket y otros datos necesarios. El servicio se
encarga de leer la tarjeta del cliente con el Pin-Pad y pedir la autorización al centro autorizador,
devolviendo el resultado (autorizada/denegada) al programa de gestión para que actúe en
consecuencia.
Si la respuesta es ‘denegada’, aunque los motivos pueden ser muy diversos (no hay fondos, no hay
conexión, tarjeta no válida,...) el resultado siempre es el mismo: la operación no se ha realizado. Es
decir, el cliente aún no ha pagado. Por tanto, el programa de gestión deberá estar preparado para esa
posibilidad, volviendo al estado anterior para permitir que se pueda pagar la operación con otra forma
de pago (normalmente efectivo) o bien volverlo a intentar con una tarjeta distinta.
Si la respuesta es ‘aceptada’, el programa de gestión deberá considerar que la transferencia ya está
realizada y podrá terminar la transacción de venta. Al cliente siempre hay que entregarle un ticket o
factura que incluya toda la información de la operación TEF. El comercio por su parte puede
imprimirse también una copia de ese ticket o simplemente guardarse la información necesaria en su
programa de gestión sin emitir ningún ticket adicional. Solo será necesario imprimir un ticket para el
comercio cuando la operación requiera la firma del cliente y no se esté utilizando un Pin-Pad con
captura de firma, ya que en ese caso el ticket firmado por el cliente es el justificante que da validez a
la transacción y el comercio puede necesitarlo ante una posible reclamación.
2.2. Devolución
La operación de devolución es la operación contraria a la venta descrita en el punto anterior. Aquí lo
que se hace es solicitar al centro autorizador que transfiera un importe determinado desde la cuenta
ligada al comercio hasta la cuenta asociada a la tarjeta del cliente.
La operativa en el punto de venta es igual: el programa de gestión manda al servicio ClearONE una
petición, el servicio lee la tarjeta del cliente, solicita la autorización al centro autorizador y devuelve el
resultado al programa de gestión, que estará preparado para los dos posibles resultados: aceptada o
denegada. Al igual que con la venta, también aquí hay que emitir siempre un ticket o factura para el
cliente. La diferencia está en la copia para el comercio, que en este caso nunca va a requerir firma ya
que ahora es el comercio quien transfiere dinero de su propia cuenta a la cuenta del cliente y no al
revés. Por ese motivo, lo más lógico sería guardarse la información necesaria en el programa de
gestión y no imprimir la copia del ticket.
Aunque el tratamiento contable de estas operaciones es igual al de las ventas, hay una diferencia que
se debe tener en cuenta para evitar malentendidos o reclamaciones de los clientes al comercio. La
diferencia está en que el ingreso del dinero en la cuenta del cliente puede demorarse algunos días,
aunque el cargo en la cuenta del comercio sí se realiza en el momento de procesar la operación.
Normalmente el ingreso no se suele demorar más de dos o tres días y de hecho, lo habitual es que el
ingreso se haga el mismo día. Sin embargo, podemos encontrarnos con transacciones que no se
completan hasta pasados seis o siete días o incluso más, dando lugar a que el cliente pueda reclamar a
la tienda. Ante esta situación no hay más remedio que pedirle paciencia al cliente: si el dinero ha
salido de la cuenta del comercio, tarde o temprano llegará a la del cliente. El motivo de este
funcionamiento está fuera del alcance de ClearONE, ya que depende de las relaciones entre los
distintos centros autorizadores (Redsýs, CECA, etc.).
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 7 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Otro aspecto a tener en cuenta es la relación entre la devolución y la venta. Dependiendo del tipo de
comercio, esta relación puede variar desde el extremo de considerarlas dos operaciones totalmente
independientes hasta el extremo opuesto de no permitir una devolución si no existe una venta previa
con la misma tarjeta y por el mismo importe. El servicio ofrecido por ClearONE pretende adaptarse
al mayor número de clientes posible y para ello, partimos de una configuración básica que es la menos
restrictiva: la venta y la devolución son dos operaciones independientes. A partir de aquí y en función
de las necesidades de cada cliente, se puede configurar el sistema para que enlace la devolución con la
venta comprobando para ello los datos que se estime convenientes (número de ticket, código de TPV,
tarjeta, importe, etc.).
2.3. Reserva de Fondos y Confirmación de Reserva
Las operaciones de reserva de fondos y confirmación de reserva se usan conjuntamente y tienen el
mismo resultado que la venta descrita en el punto 2.1. La diferencia es que usando estas dos
transacciones, el proceso se divide en dos fases o etapas. La primera etapa es hacer una reserva de
fondos para garantizar al comercio que va a poder cobrar el importe correspondiente. La segunda
etapa es confirmar esa reserva para hacer efectivo el cobro.
Esta operativa se suele utilizar en hoteles y agencias de alquiler de vehículos. En este tipo de
comercios, no hay una venta de bienes o servicios que se pueda cobrar en el momento. Lo que se hace
es dar un servicio al cliente, que lo disfruta durante algunos días y al final del periodo se le cobra por
dicho servicio. Para dar ese servicio, el comercio tiene que estar razonablemente seguro de que lo va a
poder cobrar. Esa seguridad se la da la operación de reserva de fondos.
Cuando el cliente contrata el servicio, el comercio le hace un presupuesto con el importe aproximado
del mismo. Luego, para tener una garantía de que va a poder cobrarlo, le pide la tarjeta al cliente y se
hace una petición de reserva de fondos. Esta operación bloquea el importe solicitado en la cuenta de
crédito del cliente, pero sin hacer ningún cobro. El comercio no ingresa ningún importe en su cuenta y
al cliente tampoco se le realiza ningún cargo. Simplemente se le bloquea el importe como garantía de
pago para el comercio.
Mientras la reserva está activa, se pueden pedir modificaciones de la misma para aumentar o reducir
el importe reservado. Así se puede ir ajustando el importe de la reserva al coste real que finalmente se
cobrará. Por ejemplo, cuando el cliente de un hotel decide quedarse unos días más, se pide una
ampliación del importe de la reserva para garantizar el cobro de esos días adicionales.
Una vez que el cliente ha disfrutado del servicio y se va a proceder al pago del mismo, el comercio
calcula el importe final a cobrar, que debe ser igual o inferior al importe de la reserva. Se le pide de
nuevo la tarjeta al cliente y se envía una confirmación de reserva haciendo referencia a la reserva
original e indicando el importe que finalmente se va a cobrar. En ese momento es cuando el importe
se transfiere de la cuenta del cliente a la del comercio.
El tiempo que puede transcurrir entre la reserva de fondos y la confirmación de la misma depende de
muchos factores, pero en general se puede decir que hay un plazo límite de 21 días. Si no se manda la
confirmación en ese plazo, la reserva “caduca” automáticamente y se libera el saldo bloqueado en la
cuenta de crédito del cliente.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 8 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Es importante destacar que esta operativa tiene algunas limitaciones. En primer lugar, no todos los
bancos y/o centros autorizadores la admiten. CECA, por ejemplo, no tiene esta funcionalidad, de
forma que si el comercio quiere trabajar con alguna entidad de CECA, no podrá hacer uso de ella. La
otra limitación es el tipo de tarjeta sobre la que se puede aplicar. Por definición, la reserva de fondos
solo tiene sentido con tarjetas de crédito, que son las que tienen un crédito sobre el que se puede
aplicar la reserva sin hacer un cargo. Las tarjetas de débito, como las Maestro por ejemplo, quedan
excluidas de esta operativa, salvo alguna excepción puntual como las estaciones de servicio y algún
otro tipo de comercio donde las marcas sí admiten ésta operativa. Por todo ello, hay que evaluar las
necesidades reales del comercio y valorar las ventajas y desventajas de utilizar esta operativa en lugar
de la operativa normal de venta descrita en el punto 2.1
2.4. Recarga Telefónica
Una recarga telefónica es una transacción mediante la cual el cliente incrementa el saldo de su
teléfono móvil prepago en un importe determinado. El comercio le cobra dicho importe al cliente y lo
abona a la operadora telefónica según el convenio que tenga establecido con ella, quedándose
normalmente una comisión.
La operativa en el punto de venta es relativamente simple. Los datos que se necesitan son el importe
de la recarga, la operadora telefónica y el número del teléfono móvil. El programa de gestión del
punto de venta debe obtener esos datos y a continuación enviar una petición al servicio de
ClearONE para solicitar que se realice la recarga. El servicio se encarga de todo el trabajo de
conexión y mensajería necesario, devolviendo el resultado, que nuevamente puede ser ‘aceptada’ o
‘denegada’.
Si la respuesta es ‘denegada’, aunque los motivos pueden ser muy variados (teléfono incorrecto,
importe no válido, el teléfono no es de la operadora indicada, no hay conexión,...) el resultado
siempre es el mismo: la operación no se ha realizado y al cliente no se le ha cargado el saldo en su
teléfono. El programa de gestión deberá estar preparado para esa posibilidad y en ese caso volver al
estado anterior para permitir que se introduzcan de nuevo los datos para un nuevo intento o
simplemente cancelar la operación.
Si la respuesta es ‘aceptada’, la recarga se ha completado y el cliente recibirá en su teléfono móvil un
SMS informándole de que su saldo se ha incrementado en el importe correspondiente. Lo normal es
que el mensaje lo reciba en unos segundos, cuando la transacción todavía está en curso en el punto de
venta. Pero en determinadas ocasiones el mensaje puede tardar en llegar más de lo normal, llegando
a ocurrir que el programa de gestión del punto de venta complete la transacción cuando el teléfono
aún no ha recibido el mensaje. Por ese motivo, se debe imprimir un ticket con los datos de la
operación para que el cliente tenga un justificante de que ha pagado el importe y la recarga realmente
se ha realizado. En ese justificante se incluyen entre otras cosas un número de referencia que facilita
la operadora y le sirve al cliente para cualquier posible reclamación.
Además del proceso de recarga, también hay que tener en cuenta en el punto de venta el proceso de
cobro. Lo normal es realizar primero el cobro y a continuación gestionar la recarga. Si la recarga
funciona no hay problema. Si falla, hay que devolver el importe al cliente y cancelar la transacción. En
caso de que el cobro se haya realizado con una venta TEF, para devolver el importe al cliente habrá
que hacer una devolución o una anulación TEF.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 9 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
La decisión sobre qué es mejor (cobrar antes o después de la recarga) depende del funcionamiento de
cada programa de gestión del punto de venta. Lo que hacemos nosotros aquí es poner de manifiesto
el problema para que se tenga en cuenta y que cada desarrollador le dé la mejor solución posible
según sus necesidades.
2.5. Anulaciones
Todas las operaciones anteriores (venta, devolución, reserva de fondos, confirmación de reserva y
recarga) pueden ser anuladas. La anulación se emplea cuando ocurre algo que obliga al comercio a
retroceder o eliminar una operación completada con éxito.
Por ejemplo en una recarga puede ocurrir que el operario se equivoque al teclear el teléfono,
enviando el importe de la recarga a otro teléfono distinto. En ese caso hay que anular la recarga para
hacerla de nuevo con el teléfono correcto.
En el caso de la venta o la devolución, podría ocurrir que la aplicación de gestión tuviese mal
configurados los precios y se realizase una venta o una devolución con un importe incorrecto.
También en ese caso se podría anular la operación, para realizarla de nuevo con el importe correcto.
En el caso de las reservas, siempre puede ocurrir que el cliente decida no utilizar el servicio y haya que
liberar el importe que se le ha retenido.
Hay que tener en cuenta que las anulaciones tienen ciertas restricciones. En el caso de las operaciones
TEF (venta y devolución) solo se pueden anular el mismo día en que se hacen. Esto es así porque el
importe de dichas transacciones todavía no se ha transferido a la cuenta del comercio (no se ha
cerrado la sesión contable). Una vez realizado el fin de día, ya no hay posibilidad de anular ventas o
devoluciones del día anterior. La única opción sería hacer una devolución o una venta que compensara
la operación incorrecta, pero para ello tendría que estar presente el cliente con su tarjeta.
En el caso de las recargas, los requisitos varían con cada operadora. Pero en general, no se pueden
anular recargas si han transcurrido más de 48 horas o el saldo recargado ya se ha empezado a
consumir.
En cualquiera de los casos, la anulación es una transacción cuyo uso debería estar restringido en el
programa de gestión del punto de venta. Su finalidad es únicamente la de corregir errores que,
aunque pueden darse, son poco habituales y por ello se debe utilizar con cuidado.
Otro punto a tener en cuenta es el servicio de aviso por SMS que algunos bancos ofrecen a sus
clientes. Al activar dicho servicio, el banco envía al cliente un SMS cada vez que se realiza un cargo a su
tarjeta. Pero son pocos los bancos que envían ese mismo aviso cuando lo que se hace es una
devolución y no hay prácticamente ninguno que mande SMS cuando la operación realizada es una
anulación. Esto suele llevar a confusión a los clientes, que al no recibir el SMS piensan que la
operación no se ha realizado. Ante esta situación, el personal del comercio debe tener claro que la
información correcta es siempre la que le devuelve su sistema de gestión.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 10 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
2.6. Detalle de Operaciones y Datos Ultima Operación
Estas transacciones se utilizan para obtener información de las operaciones procesadas por el sistema.
Se pueden realizar cuantas veces sea necesario porque no generan ningún movimiento de fondos.
El detalle de operaciones es una consulta que devuelve un listado con todas las transacciones
realizadas en el día. Se puede usar para comparar con los datos que tiene el programa de gestión del
punto de venta y confirmar que no hay ninguna discrepancia, para detectar y solucionar errores
debidos a cortes de corriente o similar.
La consulta sobre la última operación sirve para recuperar la respuesta del servicio a la última petición
procesada. Se puede utilizar cuando algún problema en el punto de venta hace que no se pueda
imprimir el ticket correspondiente. Usando esta transacción se recupera la información necesaria para
generar el ticket.
2.7. Consulta de Totales
La consulta de totales es una operación para obtener información. Se puede realizar cuantas veces sea
necesario porque no genera ningún movimiento de fondos. Su utilidad es la de obtener en el punto de
venta información sobre el número de operaciones de cada tipo (venta, devolución y recarga)
realizadas así como la suma del importe de las mismas.
Normalmente esta operación se realiza al final del día, cuando se está cuadrando la caja, para verificar
que los importes contabilizados por los centros autorizadores coinciden con los contabilizados en el
punto de venta (lo normal es que siempre coincidan). También puede servir para confirmar si una
operación se ha realizado, cuando algún problema grave en el punto de venta ha podido cortar una
transacción en proceso.
La consulta de totales está ligada con la operación de fin de día por el hecho de que los totales se
contabilizan siempre entre dos operaciones de fin de día. Así, el sistema empieza con los totales a cero
y cada transacción de venta, devolución o recarga va incrementando los contadores correspondientes
hasta que se realiza un fin de día, momento en que los totales se ponen de nuevo a cero.
ClearONE puede contabilizar los totales a tres niveles distintos: punto de venta, tienda o cliente. El
concepto de tienda se usa para agrupar los totales de varios puntos de venta situados en un mismo
establecimiento. Así podemos tener los totales de cada punto de venta por separado o bien la suma
de todos ellos. El concepto de cliente se usa para hacer una agrupación similar sobre las tiendas. Así
cuando hay un cliente con varios establecimientos, podemos facilitarle los totales de cada
establecimiento (tienda) por separado, o bien los totales sumados de todas las tiendas.
Y en cualquiera de los casos anteriores, los totales de operaciones TEF (venta y devolución) se
desglosan por banco o número de cuenta, pudiendo así saber la cantidad e importe de operaciones
procesadas a través de cada banco.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 11 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
2.8. Fin de Día
Como ya adelantábamos al describir la operación de venta, el movimiento de fondos asociado a cada
venta o devolución no se efectúa al procesar la operación. Lo que hace el banco es acumular todas las
operaciones realizadas a lo largo del día (lo que ellos llaman una ‘sesión contable’) para realizar un
único movimiento al final del día por el total del importe correspondiente. Para que ese movimiento
se realice es para lo que se usa la operación de fin de día.
Además de hacer el cierre con el banco y poner a cero los contadores, el Fin de día devuelve
información igual que la consulta de totales, contabilizando a tres niveles (punto de venta, tienda y
cliente) y desglosando siempre por banco o número de cuenta.
Normalmente esta operación no se realiza en el punto de venta de forma manual. Es ClearONE
quien diariamente la realiza de forma automática a una hora previamente acordada con el cliente. Al
automatizar la operación, se evita la posibilidad de errores u olvidos que podrían causar que el ingreso
no se realizara en el momento debido, acumulando los importes al ingreso de días posteriores.
Pero hay determinados tipos de comercio que necesitan controlar desde el punto de venta el
momento exacto en que se realiza el fin de día. Para estos comercios es para los que tiene sentido
utilizar la operación de fin de día.
Normalmente son grandes cadenas con muchos establecimientos que trabajan 24 horas al día y
debido al volumen de transacciones procesadas, no tienen posibilidad de cuadrar las cajas si no es
haciendo coincidir la fecha contable del establecimiento con la del banco.
En todo caso, hay que saber que no todos los bancos o centros autorizadores permiten controlar el
momento del cierre. Hay casos en los que el centro autorizador realiza el cierre de forma unilateral a
la hora que ellos deciden, normalmente a partir de las 22:00 o las 23:00. Y también hay centros que
solo admiten una operación de fin de día por cada día natural. Si se hace un fin de día a fecha uno de
Enero (digamos a las 23:00) y a continuación se intenta realizar de nuevo (por ejemplo a las 23:30), la
operación fallará ya que el día 1 de Enero ya está cerrado.
Por todo ello, hay que valorar si realmente es necesario utilizar la transacción de Fin de día desde el
punto de venta. En la mayoría de los casos, la consulta de totales es más que suficiente. Pero el Fin de
día existe y se puede utilizar.
2.9. Lectura de Tarjeta Privada
Hay comercios que utilizan tarjetas de banda magnética para fines distintos al pago (tarjetas de
fidelización, de puntos, para identificación de los operarios, etc.). Para que estas operativas funcionen,
el programa de gestión del punto de venta necesita obtener los datos grabados en la banda magnética
de la tarjeta y para ello se suele utilizar un lector de banda magnética conectado al TPV y controlado
directamente por el programa de gestión del punto de venta.
Cuando el punto de venta tiene también el cobro con tarjeta activado, tendrá normalmente un lector
Pin-Pad para leer las tarjetas de crédito/débito y teclear el PIN en aquellas que lo requieran. Como
estos lectores incluyen siempre un lector de banda magnética, se plantea la posibilidad de usar este
lector para todo, eliminando así la necesidad de tener dos lectores distintos.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 12 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Nuestro sistema permite esta arquitectura, utilizando el lector Pin-Pad para las operaciones de pago y
también para leer tarjetas de fidelización, de puntos, etc. Para ello hemos definido la transacción
“Lectura tarjeta privada” mediante la cual el programa de gestión del punto de venta manda una
petición al servicio de ClearONE para que active el lector, gestione la lectura de una tarjeta privada y
le devuelva los datos de la tarjeta leída.
La única limitación está en que las tarjetas privadas deben tener una configuración muy concreta para
que no haya conflicto con las tarjetas de pago: deben tener la información grabada en la pista 2 y la
numeración de las mismas no puede empezar por 3, 4, 5 ni 6. Si la tarjeta no cumple esas reglas el
lector considera que se trata de una tarjeta de pago y está obligado a aplicar las medidas de seguridad
impuestas por los bancos y centros autorizadores, cifrando los datos obtenidos de la tarjeta para que
nadie salvo el centro autorizador pueda tener acceso a ellos.
2.10. Venta TNA y Venta DCC
La operación de venta definida en el punto 2.1 se basa en un diálogo muy sencillo entre la aplicación
de gestión y el servicio de ClearONE: la aplicación manda una petición al servicio con el importe a
cobrar y algunos datos más, el servicio hace todo el trabajo y devuelve la respuesta a la aplicación.
Esta operativa es válida para la mayoría de los casos, pero hay ocasiones en las que no sirve. Un
ejemplo son los entornos no atendidos (máquinas vending, expendedoras de tickets, cajeros de
parking, kioscos autoservicio, etc.) en los que la aplicación que gestiona el punto de venta necesita
obtener más información del proceso de pago: si se vende un refresco o un billete de tren y el pago se
puede hacer en efectivo o tarjeta, el equipo debe activar ambos sistemas de pago, pero en cuanto se
mete una tarjeta en el lector y comienza el proceso de pago con tarjeta, el cajero debe saberlo para
desactivar el pago en efectivo.
Otro caso en el que no se puede aplicar el diálogo de la venta normal es cuando el importe a cobrar
depende de la tarjeta que se utiliza para el pago. Si el pago con una determinada tarjeta lleva asociado
un descuento, no es posible determinar el importe a cobrar hasta que comienza la transacción de
pago y se lee la tarjeta. Pero para activar el pago hay que enviar una petición al servicio y la petición
de venta normal incluye el importe a cobrar.
Para esas situaciones hemos creado la operativa “Venta TNA” que contablemente es idéntica a la
venta descrita en el punto 2.1, pero se diferencia de ella en que el diálogo entre el programa de
gestión del punto de venta y el servicio de ClearONE incluye más tramas. En esta operativa, la
petición inicial es más sencilla y no incluye el campo importe. Al recibir esa petición el servicio de
ClearONE activa el lector Pin-Pad y espera hasta que se introduzca una tarjeta. Una vez introducida,
el servicio envía al programa de gestión una trama de respuesta indicándole el resultado de la lectura
y el BIN (los primeros 6 dígitos) de la tarjeta leída. A continuación, el programa de gestión manda una
nueva trama al servicio indicándole el importe a cobrar y algunos datos adicionales. A partir de aquí la
transacción continúa como una venta normal, se envía la petición al centro autorizador, se recibe y
procesa la respuesta y finalmente se envía al programa de gestión una trama de respuesta con el
mismo formato que la venta descrita en el punto 2.1.
La otra operativa que se ha añadido al servicio es la venta DCC. Al igual que en la venta TNA, la
diferencia principal respecto a la venta “normal” es que el dialogo entre el programa de gestión y el
servicio se amplía con nuevas tramas.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 13 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
DCC es la abreviatura de “Dynamic Currency Conversion” (Conversión Dinámica de Divisa, o Moneda).
Esta operativa suele estar presente en los datafonos que los bancos facilitan a sus comercios y se
utiliza para permitir al cliente pagar en su propia moneda en lugar de en Euros. El comercio siempre
recibe el importe en Euros en su cuenta, independientemente de que se aplique DCC o no. La
diferencia está en que cuando hay DCC, la conversión de Euros a divisa la hace el banco con el que
trabaja el comercio, mientras que sin DCC es Visa Internacional o MasterCard quien realiza ese
cambio.
Usando ésta operativa, el proceso de pago en el punto de venta se modifica, mostrando el Pin-Pad un
menú de selección de moneda en el que el cliente ve el importe en euros, el contravalor en su divisa y
se le pide que seleccione la moneda con la que quiere pagar. Además, si el Pin-Pad no tiene una
pantalla con capacidad suficiente para mostrar toda la información que Visa y MasterCard consideran
necesaria, el programa de gestión del punto de venta tiene que generar un ticket informativo con toda
esta información (comisión aplicada, Mark-up, entidad que realiza el cambio, etc.) para que el
operario lo entregue al cliente.
La operativa quedaría por tanto así: el programa de gestión manda petición al servicio de ClearONE
(en este caso sí se incluye el importe a cobrar, siempre en euros). El servicio activa el Pin-Pad, lee
tarjeta, pide pin (si es necesario) y manda la petición al centro autorizador.
El centro autorizador detecta que la tarjeta es extranjera y devuelve información con el cambio a
aplicar. En ese punto el servicio manda una respuesta al programa de gestión con la información
relativa al cambio.
El programa de gestión emite el ticket informativo (si es necesario) y manda un ‘ACK’ al servicio para
que continúe la transacción. Ahora el Pin-Pad muestra el menú de selección de moneda y el cliente
elige la moneda a utilizar. Esa selección se manda al centro autorizador y la transacción se completa,
generándose la respuesta final que el servicio envía al programa de gestión en un formato muy similar
al de una venta normal.
2.11. Estado del Sistema
Esta transacción se utiliza para preguntarle al servicio de ClearONE en qué estado se encuentra el
sistema de pago. Se suele utilizar en terminales no atendidos, en los que el programa de gestión tiene
que chequear regularmente todos los módulos que componen el sistema para verificar que se
encuentran operativos, activando las correspondientes alarmas en caso contrario.
La petición se puede enviar al servicio tantas veces como sea necesario, respondiendo éste a cada
petición con una trama de respuesta en la que se informa del estado. Si todo está bien, la trama de
respuesta es un simple “TODO OK”. Si algo falla, la trama de respuesta indica el componente que está
fallando (Pin-Pad, acceso a la red, conexión con el servidor del servicio TEF, etc.)
Es importante destacar que todas las comprobaciones que se hacen con esta transacción, ya las hace
el sistema de forma automática al procesar otras transacciones como la venta o la devolución. Por
tanto, no sirve de nada lanzar una consulta de estado antes de cada venta, ya que lo único que
conseguimos es hacer dos veces lo mismo y por consiguiente, hacer que la transacción sea más lenta.
La consulta de estado del sistema solo debe usarse para aquello para lo que se ha pensado: consultar
el estado de un sistema no atendido cuando nadie lo está usando.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 14 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
2.12. Selección de idioma
Esta transacción se utiliza para indicarle al Pin-Pad el idioma que debe utilizar en la próxima
transacción que va a procesar. Se suele utilizar en kioscos o en terminales no atendidos, en los que el
programa de gestión del punto de venta admite varios idiomas y permite al cliente seleccionar el
idioma a utilizar (por ejemplo pulsando sobre la bandera de su país). Con esta transacción, se consigue
que el Pin-Pad muestre sus mensajes en el mismo idioma que el programa de gestión, ofreciendo al
usuario un interfaz más coherente y unificado.
Sin embargo, hay que tener en cuenta que no todos los Pin-Pad admiten ésta operativa. Y en aquellos
que sí la soportan, tampoco hay un comportamiento uniforme (algunos siguen con el idioma
seleccionado hasta que hay una nueva selección, otros vuelven a un idioma por defecto al completar
la transacción, etc.). Por ello, antes de usar esta operativa hay que asegurarse del Pin-Pad que se va a
utilizar y de las capacidades del mismo.
2.13. Captura de firma
Entre los distintos tipos de Pin-Pad que se pueden conectar al servicio, hay algunos que tienen una
pantalla táctil con la que se puede capturar la firma del cliente. Normalmente esta captura de firma va
asociada a las operaciones de pago con tarjeta, siendo un proceso gestionado por el servicio de
ClearONE de forma transparente al programa de gestión del punto de venta. Sin embargo, hay casos
en los que el programa de gestión puede requerir la firma del cliente para operaciones que no están
directamente relacionadas con el pago con tarjeta. Para estas operaciones es para las que se utiliza la
transacción de captura de firma.
Con esta transacción, el programa de gestión del punto de venta le pasa un texto al servicio de
ClearONE y el servicio se encarga de mostrar ese texto en la pantalla del Pin-Pad y activar el proceso
de captura de firma. Una vez completada la captura, el servicio deja la firma en el archivo que el
programa de gestión del punto de venta le ha indicado y a partir de ese momento la gestión de la
firma ya es responsabilidad del programa de gestión (evidentemente, hay que proteger esa firma con
todas las medidas de seguridad necesarias para que no se pueda hacer un mal uso de ella).
3. Instalación y Configuración del Servicio
Como ya se avanzaba en el punto 1.1, la conexión de cada punto de venta con la plataforma de
ClearONE se realiza mediante un servicio Windows (disponible también en Linux). Dicho servicio es
un programa llamado “CoServiceEMV.exe” que ClearONE facilita a sus clientes y colaboradores para
que lo instalen en los puntos de venta a conectar.
El ejecutable del servicio se acompaña con un fichero de configuración llamado “CoServiceEMV.cfg”.
Ambos ficheros deben copiarse en una carpeta del equipo, normalmente ‘\ClearOne’, aunque no es
estrictamente necesario que se llame así.
En la siguiente página mostramos un esquema funcional del servicio/componente CoServiceEMV.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 15 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Esquema Funcional del Servicio/Componente CoServiceEMV
Lo primero que hay que hacer una vez copiados ambos ficheros es editar el de configuración. Es un
fichero de texto que se puede ver con cualquier editor, por ejemplo el ‘bloc de notas’ de Windows.
Contiene una serie de secciones identificadas por un nombre entre corchetes, seguidas de una o varias
líneas de información. El carácter # se usa para incluir comentarios, de forma que toda línea que
empieza con # se ignora. Las secciones del fichero y la información que contienen se describen a
continuación.
[CONEXION] Esta sección puede tener varias líneas, hasta un máximo de 20, en las que se indican los
datos de conexión que el servicio necesita para conectarse a la plataforma de ClearONE. Cada línea
contiene una dirección IP, un puerto y un timeout de conexión, separando los campos el carácter ‘:’.
La información de esta sección es dinámica, el servicio la puede modificar con la información recibida
del servidor cambiando líneas, borrándolas o añadiendo nuevas líneas con datos de conexión para
backup.
[PROXY] Esta sección contiene la información necesaria para que el servicio pueda funcionar a través
de un Proxy. Es una única línea en la que se indica la URL o la IP del proxy, el puerto a utilizar y un
timeout de conexión, separando los campos con el carácter ‘:’.
[PUERTO] Esta sección solo tiene una línea en la que se especifica un valor numérico. Es el puerto TCP
en el que el servicio se pone a la escucha para recibir las peticiones del software de gestión del punto
de venta.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 16 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
[PROTOCOLO] Esta sección solo tiene una línea en la que se especifica un valor numérico. Es el
protocolo de comunicaciones que debe utilizar el servicio. El valor por defecto es 1, que se
corresponde con el protocolo descrito en este documento.
[CTLSRESP] Esta sección solo tiene una línea en la que se especifica un valor numérico. La utilizamos
para gestionar la nueva funcionalidad contactless manteniendo la compatibilidad con versiones
anteriores. Si se configura a 1, las tramas de respuesta del servicio cambian con respecto a versiones
anteriores para incluir los nuevos campos necesarios para el contactless. Si se pone cualquier otro
valor, el servicio mantiene las tramas de respuesta utilizadas en versiones anteriores, siendo así
compatible con todas las instalaciones realizadas hasta la fecha.
[NUMTICKRESP] Poniendo un “1” en esta sección, se modifican las tramas de respuesta que devuelve
el servicio (descritas en el punto 5.2), añadiendo un campo con el número de ticket recibido en la
petición.
[BINRESP] Poniendo un “1” en esta sección, se modifican las tramas de respuesta que devuelve el
servicio (descritas en el punto 5.2), añadiendo un campo con el ‘BIN’ de la tarjeta procesada. El BIN
son los primeros 6 dígitos de la tarjeta, que se utilizan para identifican al banco emisor de la misma.
[TAXFREERESP] Poniendo un “1” en esta sección, se modifican las tramas de respuesta que devuelve
el servicio (descritas en el punto 5.2), añadiendo el campo ‘TaxFree’ de la tarjeta procesada.
[FICHEROS] Esta sección solo tiene una línea en la que se especifica una ruta para intercambio de
ficheros.
[CLIENTE], [TIENDA], [TPV] Estos tres campos se usan para que ClearONE identifique el punto de
venta. Cada equipo en el que se instale el servicio tendrá asignado un trío de valores Cliente-TiendaTpv que le identifique de forma única. Estos valores los asigna ClearONE para cada instalación.
Es importante destacar aquí que ClearONE asocia en sus bases de datos la información de “ClienteTienda-TPV” con el MAC de la tarjeta de red del equipo. Esta asociación se hace de forma automática
la primera vez que el servicio se conecta con ClearONE, controlando así el equipo físico en el que se
instala cada servicio. Así garantizamos que nunca se pueda suplantar la identidad de un punto de
venta (Cliente,Tienda,Tpv) enviando transacciones en su nombre, ya que si la petición viene de otro
equipo distinto, el MAC de la tarjeta de red no coincidirá y se le rechazaran las peticiones. Este control
forma parte de los requisitos de seguridad que exigen los centros autorizadores. Hay que tener en
cuenta que lo que estamos haciendo es conectar el punto de venta con las redes de los centros
autorizadores y ello requiere altos niveles de seguridad.
El inconveniente es que cada vez que se cambia físicamente un equipo, o se le cambia la tarjeta de
red, hay que avisar a ClearONE para que permita la conexión del nuevo equipo.
[PINPAD] Esta sección tiene una línea en la que se indica el tipo de Pin-Pad que se va a conectar al PC,
así como el tipo de conexión (USB o serie).
[TPV_PINPAD] Esta sección se utiliza en sustitución de [TPV] + [PINPAD] para configurar un único
servicio que atienda las peticiones de todos los TPV´s de una tienda de forma simultánea. En esta
configuración el servicio no se instala en cada TPV, sino en un servidor de tienda que recibe y procesa
de forma centralizada las peticiones de pago de todos los TPV´s de la tienda.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 17 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
[TIENDA_PINPAD] Esta sección se utiliza en sustitución de [TIENDA] + [TPV] + [PINPAD] para
configurar un servicio que atienda las peticiones de todos los TPV´s de múltiples tiendas de forma
simultánea. En esta configuración el servicio se instala en un servidor centralizado que recibe y
procesa las peticiones de pago de todos los TPV´s de varias tiendas.
[TPV_PSERIE] Esta sección es similar a TPV_PINPAD, pero añadiendo la información necesaria para
comunicar con un programa de TPV por conexión serie en lugar de la conexión TCP descrita en este
documento.
[CAB_TICKET] En esta sección se pueden configurar hasta 6 líneas de texto de un máximo de 40
caracteres cada una para utilizarlas como cabecera en los tickets que generan los Pin-Pad que tienen
impresora.
[DEBUG] Esta sección tiene una única línea en la que se especifica un valor numérico entre 0 y 4. Si se
pone a cero, no aparece ningún mensaje en el fichero de log. Si se pone a 4, aparecen en el log la
mayor cantidad posible de mensajes, para tener un registro de lo que hace el servicio. La
recomendación de ClearONE es usar siempre el valor 4. El tamaño del fichero log está limitado para
que no crezca indefinidamente, por lo que nunca habrá problemas de espacio debido a este fichero.
En cuanto al contenido del mismo, tampoco genera ningún problema de seguridad o privacidad. La
información que se graba en el fichero cumple con todos los requisitos derivados del PCI-DSS, de
forma que no hay información sensible que pueda ser utilizada por ningún usuario malintencionado.
Una vez tengamos el fichero de configuración revisado, podemos pasar a instalar el servicio. Para ello
hay que abrir una ventana MS-DOS, situarse en el directorio en el que se han copiado ambos ficheros
y ejecutar “CoServiceEMV –i”. Si todo es correcto, se mostrará en pantalla el mensaje “Servicio
correctamente instalado” y aparecerá un fichero llamado ‘CoServiceEMV.log’ en el que el servicio deja
un log de las operaciones realizadas. A continuación podemos abrir el administrador de servicios de
Windows y poner en marcha el servicio. Si todo es correcto, el servicio se conectará con ClearONE,
intercambiaran las claves necesarias para trabajar y se creará el fichero ‘CoServiceEMV.bin’ en el que
se guarda toda esa información. A partir de ese momento, la conexión con ClearONE ya está
disponible y el servicio está a la escucha para recibir y procesar las peticiones que le envíe el software
de gestión del punto de venta.
4. Cómo Integrar ClearONE en un Programa de Gestión
El servicio descrito en el punto anterior tiene la misión de recibir peticiones del programa de gestión y
procesarlas devolviendo la respuesta correspondiente al mismo. Toda la información intercambiada
entre las dos aplicaciones se codifica en tramas de datos con formato ASCII, que se envían y reciben a
través de sockets TCP/IP. Para ello, el servicio abre un puerto de escucha TCP en la dirección local del
PC (127.0.0.1) utilizando el número de puerto definido en el fichero de configuración. Y cada vez que
el programa de gestión requiere los servicios de ClearONE, se conecta al socket del servicio, le
manda la trama de petición con toda la información necesaria y espera la respuesta por la misma
conexión.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 18 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
La decisión de utilizar un servicio y comunicaciones TCP para enlazar el software de gestión con
ClearONE se ha tomado después de valorar detenidamente otras posibles opciones como el uso de
librerías DLL o drivers OPOS. Y lo que se pretende con dicha decisión es permitir una fácil integración
al mayor número de desarrolladores posible. Si hubiésemos optado por generar una DLL, estaríamos
limitando la conexión a los programas desarrollados en un lenguaje determinado, a menos que
generásemos tantas DLL’s como lenguajes hay en el mercado. Además, los tipos de datos que utiliza
cada lenguaje de programación son distintos, causando multitud de problemas en el proceso de
integración. En cuanto a los drivers OPOS, no hay ningún tipo de dispositivo estándar en las
especificaciones que se adapte a lo que ofrece nuestro servicio. Y en caso de que lo hubiera, también
tendríamos que generar varios drivers distintos (OPOS estándar, OPOS para Java, OPOS para .NET,
etc.)
4.1. Un Ejemplo en C++
Lo más gráfico para cualquier programador es ver un ejemplo en código. A continuación mostramos
una sencilla función que establece conexión con el servicio, le envía una trama de datos previamente
generada, espera la respuesta del servicio y una vez recibida la confirma con una trama de ACK y cierra
la conexión. El código del ejemplo está escrito en C++ porque ese es el lenguaje que ClearONE utiliza
habitualmente para sus desarrollos. Pero es suficientemente intuitivo como para que cualquier
programador lo entienda, independientemente del lenguaje en el que trabaje.
Lo primero que hace la función es crear un socket y establecer conexión con la IP 127.0.0.1 y el puerto
‘port’ que recibe en los parámetros. Se supone que en esa IP y puerto está escuchando el servicio.
Una vez conectados con el servicio, le mandamos la trama de petición, un array de caracteres que la
función recibe en ‘pet’ y se supone que contiene la información necesaria para pedirle al servicio que
procese una determinada transacción. Más adelante en este mismo documento se describe el formato
de las tramas a utilizar.
Después de enviar la petición, hacemos una llamada a ‘recv’ que termina cuando el servicio nos envía
la respuesta correspondiente (o cuando se cierra o se pierde la conexión). Comprobamos a
continuación que realmente hemos recibido la respuesta y si es así, generamos una trama de
aceptación y la mandamos al servicio para confirmarle que hemos recibido la respuesta
correctamente. Finalmente, cerramos el socket y terminamos, devolviendo el tamaño de la respuesta
recibida.
Ver el ejemplo de código en la siguiente página
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 19 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
int ProcesaTRN ( char *pet, int tampet, char *resp, int tamresp, short port )
{
SOCKET
sock;
structsockaddr_in
dir;
int
tam;
char
ack[5];
tam = 0;
sock = socket ( AF_INET , SOCK_STREAM , 0 );
dir.sin_family = AF_INET;
dir.sin_addr.S_un.S_un_b.s_b1 = 127;
dir.sin_addr.S_un.S_un_b.s_b2 = 0;
dir.sin_addr.S_un.S_un_b.s_b3 = 0;
dir.sin_addr.S_un.S_un_b.s_b4 = 1;
dir.sin_port = htons ( port );
if ( connect ( sock , (SOCKADDR *)&dir, sizeof(dir) ) !=0 )
{
if (send (sock, pet, tampet, 0) == tampet)
{
if ( (tam = recv (sock, resp, tamresp, 0)) > 0)
{
ack[0] = 0x02;
ack[1] = ‘A’;
ack[2] = ‘C’;
ack[3] = ‘K’;
ack[4] = 0x03;
send (sock, ack, 5, 0);
}
}
closesocket ( sock );
}
return tam;
}
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 20 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
5. Formato de las tramas de datos
Todas las tramas intercambiadas entre la aplicación de gestión del punto de venta y el servicio de
ClearONE tienen la misma estructura. Son cadenas de caracteres ASCII que empiezan con un
carácter de cabecera, siguen con una serie de campos de longitud variable separados entre sí por un
separador de campos y terminan con un carácter de fin de trama:
[STX]Campo1;Campo2;…;CampoN[ETX]
El carácter de cabecera es el [STX] (Start of text) , que tiene el valor ASCII 2. El carácter de fin de trama
es el [ETX] (End of text), con el valor ASCII 3. Y el separador de campos es el punto y coma, el ASCII 59.
Lógicamente, los campos de la trama no pueden incluir ninguno de los tres caracteres anteriores, pues
de lo contrario se interpretarían mal los límites de los campos o de la propia trama.
Por último, resaltar el hecho de que el último campo de la trama no va seguido de un separador. El
carácter de fin de trama que le sigue es el que marca el límite de dicho campo y también de la trama.
El diálogo normal que se utiliza en prácticamente todas las transacciones procesadas por el servicio
consiste siempre en el intercambio de tres tramas: una petición del programa de gestión al servicio,
una respuesta del servicio al programa de gestión y una trama de confirmación o “ACK” del programa
de gestión al servicio. Estas tramas se describen en los tres puntos siguientes.
Las tramas utilizadas por ciertas transacciones que requieren un diálogo extendido distinto al anterior,
se describen en el punto 5.4
5.1. Tramas de petición
Las tramas de petición tienen una cabecera común y luego ‘datos adicionales’, una serie de campos
que dependen del tipo de trama. El formato de estas tramas es:
[STX]Cliente;Tienda;Tpv;Operario;Ticket;TipoOp[DatosAdicionales][ETX]
Los campos de la cabecera sirven para identificar el origen de la transacción y el tipo de la misma. Este
es el significado de cada uno de ellos:
Cliente,Tienda,Tpv: Son campos numéricos, en el rango 1-999999999, que asigna ClearONE en cada
instalación para identificar de forma única a cada punto de venta que se conecta con la plataforma.
Operario: Es el código del operario que está trabajando en el punto de venta. Es un campo de texto
que puede tener desde 0 hasta 20 caracteres.
Ticket: Es el número de ticket que asigna el software de gestión del punto de venta a la transacción en
curso. Es un campo de texto entre 0 y 20 caracteres. Este campo es el que se devuelve en la trama de
respuesta cuando se activa la sección [NUMTICKRESP] en el fichero cfg.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 21 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
TipoOp: Es un campo numérico que indica el tipo de operación que se está solicitando al servicio. Los
valores posibles son:
1-Venta
2-Devolución
3-Recarga telefónica
4-Reserva de fondos
5-Confirmación de reserva
6-Taxfree*
11-Anula venta
12-Anula Devolución
13-Anula Recarga
14-Anula reserva
15-Anula confirmación reserva
16-Anula taxfree*
21-Totales Cliente
22-Totales Tienda
23-Totales Tpv
31-FinDiaCliente
32-FinDiaTienda
33-FinDiaTpv
41-Detalle de operaciones
42-Datos última operación
43-Lectura tarjeta privada
44-Venta TNA
45-Estado Sistema
46-Venta DCC
47-Selección de idioma
48-Captura de firma
* Estas transacciones se describen en detalle en el documento “Anexo Tax Free”.
Y en función del tipo de operación, los datos adicionales pueden ser cero, uno o varios campos,
siempre con el formato estándar y separados por el separador de campos ‘;’. Estos son los campos
para cada tipo de operación:
1-Venta:
2-Devolucion:
3-Recarga:
4-Reserva:
5-Conf.Res.:
11-Anul.Vta:
12-Anul.Dev:
13-AnulRec:
14-Anul.Res.:
15-Anul.Conf:
21,22,23-Totales:
31,32,33-FinDia:
41-Detalle OP’s:
42-Ultima OP.:
43-Lect.Trj.Priv:
44-Venta TNA:
45-Estado sist.:
46-Venta DCC:
47-Sel.Idioma:
48-Captura Firma:
12/05/2015
;Importe;Banco;PagoAplazado;;;PAN;Caducidad;CVV
;Importe;Banco;;;PAN;Caducidad;NumOpOrg;FechaOpOrg
;Importe;Operadora;Telefono
;Importe;Banco;NumOpCO;;;PAN;Caducidad;CVV
;Importe;NumOpCO;;;PAN;Caducidad;CVV
;Importe;NumOpCO;NumOpBco;CodAut
;Importe;NumOpCO;NumOpBco;CodAut
;Importe;NumOpCO;LocalRef;OperatorRef
;Importe;NumOpCO;NumOpBco;CodAut
;Importe;NumOpCO;NumOpBco;CodAut
;FechaConsulta
[;FechaConsulta[;Ticket]]
;Importe;Banco;PagoAplazado
;Idioma
;NomFich;TextoLibre
Protocolo de Conexión C le ar O N E versión 1.5
Página 22 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Nota: Página anterior: Como se puede ver, en las tramas 1, 2, 4 y 5 aparecen tres “;” consecutivos.
No es ninguna errata, son campos que en la actualidad no se utilizan pero que mantenemos
en las tramas por compatibilidad con versiones previas.
Y a continuación se explica el formato de cada campo:
Importe: Campo numérico en el rango 1-999999999. No lleva signo ni separador decimal y las dos
últimas cifras se entienden como decimales. Así, el valor 1 significa 0,01€, el valor 100 significa 1,00€ y
el máximo posible, 999999999, equivale a 9.999.999,99 €.
Banco: Campo numérico en el rango 1-9999 que se usa para indicar que la transacción debe enviarse a
un banco determinado. Con esto permitimos que el punto de venta pueda trabajar con varios bancos
y elegir en cada operación el banco que debe procesarla. La codificación de este campo se basa en la
establecida por el banco de España en el “Registro oficial de entidades”, accesible vía internet:
http://www.bde.es/servicio/regis/regent.htm. En ciertas configuraciones especiales, se utiliza este
campo como ‘Código de empresa’, siendo en ese caso un campo texto de hasta 8 caracteres que se
utiliza para identificar los distintos comercios disponibles e indicar cuál de ellos debe utilizarse en la
transacción actual.
PagoAplazado: Campo numérico en el rango 0-9999 que se utiliza en las tarjetas privadas para indicar
desde el punto de venta la forma de pago a utilizar (debito, crédito, pago aplazado a 3 meses, etc.) La
codificación exacta depende del tipo de tarjeta.
PAN: Personal Account Number, el número de la tarjeta del cliente. Se utiliza en entornos WEB
cuando la captura de los datos de la tarjeta se hace en la página del comercio. La longitud de este
campo está entre 0 y 19 dígitos.
Caducidad: Se utiliza en conjunto con el campo anterior para realizar la transacción en entornos WEB.
El formato es MMAA, tal como viene impreso en el relieve de las tarjetas.
CVV: Campo numérico entre 0 y 5 dígitos, que se utiliza junto con los dos anteriores para dar mayor
seguridad a las transacciones realizadas con tecleo de tarjeta. Es el valor numérico que figura en el
reverso de las tarjetas y se suele utilizar en la compra por internet.
NumOpOrg: Es un campo que se usa únicamente en las devoluciones para ligarlas con una operación
de venta previa. Aquí se debe enviar el número de operación asignado por el banco a la venta original.
Dependiendo del banco con el que se trabaje, puede ser necesario utilizar este campo para poder
hacer devoluciones.
FechaOpOrg: Como el anterior, este campo solo se utiliza en devoluciones. Aquí se indica la fecha de
la venta original. El formato es ddmmaa. Y del mismo modo que el anterior, solo se utiliza con
determinados bancos.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 23 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Operadora: Un campo numérico para identificar a las operadoras telefónicas. Se utiliza en las recargas
telefónicas y los valores permitidos a fecha de hoy son:
1-Movistar
2-Vodafone
3-Orange
4-Yoigo
5-Euskaltel
6-Lebara Móviles
7-Carrefour
8-Masmovil
9-E-Plus
10-Llamaya
11-Simyo
12-Blau
13-DIGI.mobil
14-Lycamobile
15-Orbitel Móvil
16-Ortel
17-Tuenti
18-GT Mobile
19-hits mobile
20-happy móvil
21-JAZZTEL
22-MovilDIA
Telefono: Número de teléfono al que se hace la recarga. El formato del campo es el de los números de
teléfono de los móviles españoles: 9 dígitos, empezando siempre por 6 ó 7.
NumOpCO: Campo numérico en el rango 1-999999999. Se utiliza en las transacciones de reserva y las
anulaciones, para hacer referencia a la transacción original. Este es el número de operación que asigna
ClearONE a cada transacción que procesa.
NumOpBco: Campo numérico en el rango 1-9999999. Se utiliza en las anulaciones de venta o
devolución para identificar la transacción que se quiere anular. Es el número de operación que asigna
el banco o centro autorizador a cada transacción que procesa.
CodAut: Campo de texto entre 1 y 6 caracteres (ojo: puede incluir el carácter espacio, ASCII 32). Se
utiliza en las anulaciones de venta o devolución para identificar la transacción que se quiere anular. Es
el código de autorización que asigna el banco o centro autorizador a cada transacción que procesa y
acepta.
LocalRef: Campo de texto de hasta 20 caracteres (ojo: puede incluir el carácter espacio, ASCII 32). Se
utiliza en las anulaciones de recargas para identificar la transacción que se quiere anular. Es el
identificador de transacción que asigna el centro autorizador a cada transacción que procesa.
OperatorRef: Campo de texto de hasta 20 caracteres (ojo: puede incluir el carácter espacio, ASCII 32).
Se utiliza en las anulaciones de recargas para identificar la transacción que se quiere anular. Es el
código de autorización que asigna el centro autorizador a cada transacción que procesa y acepta.
FechaConsulta: Campo numérico en formato aaaammdd. Se utiliza en las consultas de totales para
indicar la fecha de la consulta, pudiendo así obtener los totales de días anteriores ya cerrados. Si no se
utiliza, se entiende que la consulta es para el día actual. Opcionalmente se puede usar también en el
detalle de operaciones para obtener los datos de días anteriores.
Ticket: Se usa en el detalle de operaciones para obtener solo aquellas que en la trama de petición
tenían ese valor en el campo del mismo nombre. Al igual que ‘FechaConsulta’ es un campo opcional,
pero en este caso no se puede usar de forma individual: si se quiere utilizar, es obligatorio utilizar
también ‘FechaConsulta’.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 24 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Idioma: Es un campo numérico que identifica el idioma a utilizar por el Pin-Pad. La lista de idiomas
disponibles actualmente es:
0-Español
1-Ingles
2-Francés
3-Alemán
4-Catalán
5-Valenciano
6-Euskera
7-Gallego
8-Portugués
9-Italiano
10-Español (México)
NomFich: Campo texto de hasta 100 caracteres. Se usa en la captura de firma, es el nombre del
fichero de salida que contendrá la firma capturada por el Pin-Pad.
TextoLibre: Campo texto de hasta 120 caracteres. Se usa en la captura de firma, es el texto que el PinPad mostrará en su pantalla al solicitar la firma del cliente. El texto se muestra en 4 líneas de 30
caracteres cada una de ellas.
A continuación mostramos algunas tramas de ejemplo:
[STX]9999;100;1;LUIS;P-1234;1;1520;;;;;;;[ETX]
Esta trama es una petición del cliente 9999, tienda 100, TPV 1, que está utilizando el operario ‘LUIS’ y
está generando el ticket ‘P-1234’. En la trama se pide autorización para una venta de 15,20 € sin
especificar ni el banco al que se debe mandar, ni los datos de la tarjeta. Ante esta petición, el servicio
activará el Pin-Pad para que el cliente introduzca su tarjeta y procesará la transacción enviándola al
banco que tenga configurado por defecto el punto de venta indicado.
La siguiente trama es una petición para realizar una recarga telefónica de 20,00 € al teléfono
666666666, de la operadora Vodafone (2). En este caso se está generando el ticket 000001 pero no se
indica el código o nombre de operario, lo cual es perfectamente válido.
[STX]9999;100;1;;000001;3;2000;2;666666666[ETX]
En la siguiente trama, se solicita la anulación de una devolución. La devolución era de 15,30 €, tenía el
número de operación 123456 para ClearONE, el número de operación 654321 para el centro
autorizador y el código de autorización ‘1F349D’
[STX]9999;100;1;;;12;1530;123456;654321;1F349D[ETX]
Por último, una trama para consultar los totales contabilizados a nivel de tienda el día 2 de Enero de
2015, podría ser la siguiente:
[STX]9999;100;1;;;22;20150102[ETX]
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 25 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
5.2. Tramas de respuesta
Las tramas de respuesta tienen una cabecera común con dos campos y luego una serie de campos que
dependen del tipo de trama. El formato de estas tramas es:
[STX]CodResult;Texto[DatosAdicionales][ETX]
CodResult: Es el resultado de la transacción procesada. Es un campo numérico que puede tener signo.
El valor 0 siempre indica operación aceptada o procesada correctamente. Cualquier otro valor indica
que la operación no se ha podido realizar.
Texto: Contiene un literal que explica el resultado de la transacción. Es un campo que el programa de
gestión del punto de venta debería mostrar tal cual al operario para que éste pueda ver el motivo por
el que la operación no se ha realizado.
Y en función del tipo de transacción en proceso, los datos adicionales son unos u otros. A continuación
se detallan los campos para cada tipo de operación:
Venta (tipo 1, no TNA ni DCC), Devolución, Reserva de fondos, Confirmación de reserva y anulación de
todas ellas (con la configuración contactless activada, [CTLSRESP] a 1):
;Ticket;NumOpCO;FechaContable;TipoOp;Importe;Moneda;AID;LBL;BIN;
Tarjeta(enmascarada);TxtMarca;Titular;Pais;Emisor;Red;TipoTarjeta;TaxFree;Comercio;
Terminal;IdSesion;TxtBanco;ARC;NumOpBco;CodAut;NumRefTP;TipoLectura;CVM
Si no se activa la configuración contactless, los campos son los mismos que en versiones anteriores:
[;Ticket];NumOpCO;TipoOp;Importe;AID;LBL[;BIN];Tarjeta(enmascarada);
TxtMarca;Titular[;TaxFree];Comercio;Terminal;TxtBanco;ARC;NumOpBco;
CodAut;NumRefTP;PedirFirma
Recarga y Anulación de recarga:
[;Ticket];NumOpCO;TipoOp;Operadora;Telefono;Importe;
Comercio;Terminal;NumOpCO*);LocalRef;OperatorRef
* NumOpCO aparece dos veces en la trama, está así por compatibilidad con versiones anteriores.
Consultas de totales y Fines de día:
[;Ticket];NumOpCO;TipoOp;
NumDesgloses[Desglose-1...Desglose-N];NumRecargas;ImpRecargas
y el formato de cada desglose es:
;NomBanco;NumVentas;ImpVentas;NumDevols;ImpDevols
Detalle de operaciones: se explica en el punto 5.4
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 26 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Última operación: el mismo formato que la venta o la recarga, dependiendo de cuál haya sido la
última transacción realizada
Lectura de tarjeta privada:
[;Ticket];Pista2
Venta TNA: se explica en el punto 5.4.
Estado del sistema: no tiene datos adicionales.
Venta DCC: se explica en el punto 5.4.
Selección de idioma: no tiene datos adicionales.
Captura de firma: no tiene datos adicionales.
Hay que tener en cuenta que los campos de datos adicionales solo aparecen con total seguridad en las
tramas de respuesta cuando la transacción se acepta, es decir, cuando CodResult es 0. Si la
transacción se ha denegado, los datos adicionales pueden aparecer o no en la trama según el motivo
por el que se haya denegado la operación. La aplicación de gestión del punto de venta debe tener esto
en cuenta, para aceptar como válidas las respuestas en las que no hay ningún dato adicional,
independientemente del tipo de transacción en proceso.
A continuación explicamos el formato de cada uno de los campos anteriores
Ticket: Este campo aparece en la trama de respuesta cuando está activada la configuración contactless
o cuando se ha activado la sección [NUMTICKRESP] en el fichero cfg, como ya se ha explicado
anteriormente. El servicio de ClearONE devuelve en este campo el valor recibido en la trama de
petición, para que el programa de gestión del punto de venta pueda ligar la respuesta con la petición
original.
NumOpCO: Campo numérico en el rango 1-999999999. Este campo es el identificador único que
ClearONE asigna a la transacción procesada. Con este valor se puede identificar de forma única la
transacción en las bases de datos de ClearONE para posteriores consultas, anulaciones, etc.
FechaContable: Es la fecha que asigna Clea rONE a la transacción procesada, teniendo en cuenta el
horario de cierre de cada cliente, las operaciones de Fin de día y todo lo que se ha explicado en puntos
anteriores. Se envía en formado AAAA/MM/DD
TipoOp: Campo de texto que indica el tipo de operación procesada (VENTA, DEVOLUCION, RECARGA,
etc.)
Importe: Campo numérico en el rango 1-999999999. No lleva signo ni separador decimal y las dos
últimas cifras se entienden como decimales. Así, el valor 1 significa 0,01€, el valor 100 significa 1,00€ y
el máximo posible, 999999999, equivale a 9.999.999,99 €. Es el importe autorizado en la transacción.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 27 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Moneda: Campo de texto de 3 caracteres que indica la moneda en la que se ha realizado la
transacción. Tendrá siempre el valor ‘EUR’ salvo en los casos en que se aplica el DCC, descrito más
adelante en este mismo documento.
AID: Campo de texto que identifica la aplicación de la tarjeta chip con la que se ha realizado la
transacción. Tiene una longitud máxima de 32 caracteres.
LBL: Campo de texto que contiene un nombre descriptivo asociado al AID anterior. Tiene una longitud
máxima de 16 caracteres.
BIN: Este campo aparece en la trama de respuesta cuando está activada la configuración contactless o
cuando se ha activado la sección [BINRESP] en el fichero cfg. Es un campo numérico de 6 dígitos que
contiene el BIN de la tarjeta utilizada en la transacción. A partir de esta información se puede
identificar el banco emisor de la tarjeta, su nacionalidad y algunos datos más que pueden resultar de
utilidad para el comercio.
Tarjeta(enmascarada): Campo de texto en el que aparece el número de la tarjeta del cliente
formateado tal como exigen los bancos por motivos de seguridad, ocultando todos los dígitos con el
carácter ‘*’ salvo los 4 últimos. Puede tener hasta 19 caracteres, ya que esa es la máxima longitud
válida para una tarjeta de pago.
TxtMarca: Campo de texto que contiene la marca de la tarjeta utilizada en la transacción (Visa,
Mastercard, Amex, etc.). Puede tener hasta 30 caracteres.
Titular: Campo de texto de hasta 26 caracteres. Es el nombre del titular de la tarjeta.
Pais: Campo numérico de 3 dígitos que indica el país emisor de la tarjeta. La codificación de este
campo se corresponde con el estándar ISO 3166, que asigna un código numérico de tres dígitos a cada
país.
Emisor: Campo numérico de 4 dígitos que identifica el banco emisor de la tarjeta (cuando es
conocido). Para las tarjetas emitidas por bancos nacionales, utilizamos la misma codificación que se ha
descrito antes para el campo ‘Banco’ de las tramas de petición (el registro oficial de entidades del
banco de España). Para el resto de tarjetas, se manda siempre el valor 9999 que indica “emisor
desconocido”.
Red: Campo numérico de un dígito que identifica la red a la que pertenece la tarjeta, de acuerdo a la
codificación establecida en la siguiente tabla:
1-Servired
2-4B
3-Euro 6000
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 28 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
TipoTarjeta: Campo de texto de 2 caracteres que indica el tipo de la tarjeta utilizada en la transacción.
El primer carácter indica si la tarjeta es de crédito o de débito. El segundo dice si se trata de una
tarjeta de empresa o de particular. Los valores que utilizamos para ambos datos son:
C-Tarjeta de crédito
D-Tarjeta de débito
O-Otras
E- Tarjeta de Empresa
C- Consumo (tarjeta de un particular)
O- Otras
TaxFree: Campo numérico que puede tomar los valores 0 o 1. Cuando está a 1 indica que la tarjeta
utilizada en la transacción es de algún país al que se puede hacer TaxFree. Esta operativa se describe
en detalle en el documento “Anexo Tax Free”.
Comercio: Campo de texto de hasta 15 caracteres. Es el número de comercio que el centro
autorizador asigna al establecimiento o comercio en el que se realiza la transacción.
Terminal: Campo de texto de hasta 11 caracteres. Junto con el número de comercio anterior,
identifica el punto de venta de cara al banco o centro autorizador.
IdSesion: Campo numérico de 9 dígitos que identifica la sesión contable en la que el banco ha
contabilizado esta transacción.
TxtBanco: Campo de texto de hasta 30 caracteres. Es el nombre del banco a través del que se ha
procesado la transacción.
ARC: Campo de texto de 2 caracteres. Es el resultado de la transacción EMV.
NumOpBco: Campo numérico en el rango 1-9999999. Este número lo asigna el centro autorizador
para identificar esta transacción.
CodAut: Campo de texto entre 1 y 6 caracteres (ojo: puede incluir el carácter espacio, ASCII 32). Es el
código de autorización que asigna el banco o centro autorizador a la transacción cuando la acepta.
NumRefTP: Campo numérico en el rango 1-9999999. Este número lo asigna el centro autorizador para
identificar esta transacción. Se usa en Tarjetas Privadas.
TipoLectura: Campo numérico de un dígito que indica la forma en que el Pin-Pad ha leído la tarjeta.
Los valores posibles se indican en la siguiente tabla:
1-Chip
2-Banda magnética
3-Tecleo manual
4-Tarjeta Contactless
5-Móvil NFC
CVM: Campo numérico de un dígito que indica la forma en que se ha verificado la identidad del titular
de la tarjeta. Los valores posibles se indican en la siguiente tabla:
1-Operación con PIN, firma no necesaria
2-Operación contactless, firma no necesaria
3-Firma capturada por el Pin-Pad
4-Hay que pedir firma en el ticket
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 29 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
PedirFirma: Campo numérico que puede tomar los valores 0 o 1. El 1 indica que hay que pedir la firma
del titular de la tarjeta. El 0 indica que no es necesario, normalmente porque la operación se ha
realizado con PIN.
Operadora: Campo de texto de hasta 20 caracteres. Contiene el nombre de la operadora con la que se
ha gestionado la recarga telefónica
Telefono: Número de teléfono que se ha recargado. El formato del campo es el de los números de
teléfono españoles: 9 dígitos, empezando siempre por 6 ó 7.
LocalRef: Campo de texto de hasta 20 caracteres. Es el identificador de transacción que asigna el
centro autorizador a cada transacción que procesa.
OperatorRef: Campo de texto de hasta 20 caracteres. Es el código de autorización que asigna el centro
autorizador a la transacción cuando la acepta.
NumDesgloses: Campo numérico en el rango 0-9999. Es un contador que indica el número de
desgloses que vienen a continuación en la trama.
NomBanco: Campo de texto de hasta 30 caracteres. Es el nombre del banco al que pertenecen los
totales de este desglose.
NumVentas: Campo numérico en el rango 0-999999999. Es el número de ventas aceptadas por el
banco indicado en el campo anterior.
ImpVentas: Campo numérico de hasta 18 dígitos. Es el importe sumado de todas las ventas aceptadas
por el banco.
NumDevols: Campo numérico en el rango 0-999999999. Es el número de devoluciones aceptadas por
el banco.
ImpDevols: Campo numérico de hasta 18 dígitos. Es el importe sumado de todas las devoluciones
aceptadas por el banco.
NumRecargas: Campo numérico en el rango 0-999999999. Es el número de recargas telefónicas
aceptadas por el centro autorizador.
ImpRecargas: Campo numérico de hasta 18 dígitos. Es el importe sumado de todas las recargas
telefónicas aceptadas por el centro autorizador.
Pista2: Datos obtenidos por el lector de banda magnética al utilizar la transacción de lectura de tarjeta
privada.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 30 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
A continuación mostramos algunas tramas de ejemplo:
[STX]-301;Error de sesion con el servidor[ETX]
La trama anterior es una respuesta válida del servicio, en la que se indica que no ha podido procesar la
transacción solicitada porque no ha podido establecer una sesión de comunicaciones con el servidor
ClearONE.
[STX]0;OPERACION ACEPTADA;Tick001;2889041;2015/03/16;VENTA;123;EUR;
A0000000031010;Visa Credit;459988;************3006;VISA;LOPEZ PEREZ/JESUS;
724;0182;1;DC;0;123456789;00000001;150316001;CaixaBank;00;583246;747663;0;1;1[ETX]
La trama anterior es la respuesta a una petición de venta de 1,23 € para el ticket ‘Tick001’. En este
caso, se ha aceptado la transacción, asignándole ClearONE la fecha contable 2015/03/16 y el
número de transacción 2889041. El banco por su parte ha contabilizado la transacción en la sesión
contable 150316001 con número de operación 583246 y código de autorización 747663. La tarjeta
que se ha utilizado era española (724), emitida por BBVA (0182) y el valor ‘DC’ indica que era de débito
y de un particular. El 1;1 al final de la trama indica que es una tarjeta chip y que el titular ha tecleado
su PIN.
La siguiente trama es la respuesta que habría generado el servicio para la misma petición si no tuviera
activado el [CTLSRESP].
[STX]0;OPERACION ACEPTADA;2889041;VENTA;123;A0000000031010;
Visa Credit;************3006;VISA;LOPEZ PEREZ/JESUS;
123456789;00000001;CaixaBank;00;583246;747663;0;1[ETX]
Y la siguiente trama es la respuesta a una consulta de totales a nivel de tienda. En este caso, el
establecimiento ha trabajado con dos bancos, BBVA y CaixaBank. Con BBVA se han realizado 10 ventas
que suman un total de 230,45€. Con CaixaBank se han procesado 5 ventas por un total de 180,00€ y 1
devolución de 15,90€. Además, se han realizado 3 recargas telefónicas que suman un total de 40,00€.
[STX]0;OPERACION ACEPTADA;123456789;TOTALES TIENDA;2;
BBVA;10;23045;0;0;CaixaBank;5;18000;1;1590;3;4000[ETX]
5.3. Trama de ACK
El ACK es un mensaje que la aplicación de gestión del punto de venta manda al servicio para
confirmarle que ha recibido la respuesta. La misión de esta trama es controlar los errores que pueden
darse en cualquier comunicación entre dos procesos independientes.
Si el servicio procesa una transacción y manda la respuesta al programa de gestión, pero no recibe la
trama de confirmación, se entiende que la respuesta no ha llegado correctamente al programa de
gestión. Esto puede ocurrir si el programa de gestión se bloquea o corta la conexión por cualquier
motivo. Si la operación procesada es venta, devolución, reserva de fondos o recarga y el centro
autorizador la ha aceptado, el servicio generará una anulación automática, ya que la transacción no se
ha podido completar puesto que el programa de gestión no ha recibido correctamente la información.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 31 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
El formato de la trama es fijo, su única utilidad es garantizar que la conexión sigue abierta y el proceso
de gestión del punto de venta ha recibido la respuesta. La trama de ACK es siempre igual:
[STX]ACK[ETX]
Siendo ACK tres caracteres ASCII, la ‘A’, la ‘C’ y la ‘K’.
5.4. Diálogos extendidos: detalle de operaciones, venta TNA y venta DCC
Como ya se ha comentado antes, hay transacciones en las que el diálogo estándar (petición-respuestaack) no es suficiente. Una de ellas es la 41-Detalle de operaciones. En esta transacción, el programa de
gestión del punto de venta solicita al servicio de ClearONE un listado con todas las operaciones
procesadas el día actual o en una fecha concreta. Para devolver esa información, una sola trama de
respuesta del servicio es insuficiente. Lo que se hace en este caso es enviar una trama por cada
transacción esperando un ACK del programa de gestión antes de enviar la siguiente. El diálogo queda
por tanto así:
---> [STX]Cliente;Tienda;Tpv;Operario;Ticket;41…[ETX]
<--- [STX]aaaa/mm/ddhh:mm:ss[DatosAdicionales][ETX]
---> [STX]ACK[ETX]
<--- [STX]aaaa/mm/ddhh:mm:ss[DatosAdicionales][ETX]
---> [STX]ACK[ETX]
.
.
.
<--- [STX]aaaa/mm/ddhh:mm:ss[DatosAdicionales][ETX]
---> [STX]ACK[ETX]
<--- [STX][ETX]
---> [STX]ACK[ETX]
Las tramas de datos que manda el servicio son iguales a las que mandó al aceptar la operación original
(descritas en el punto 5.2), pero sustituyendo los campos iniciales “CodResult” y “Texto” por un campo
con la fecha y hora en que se procesó la transacción.
Como el detalle solo devuelve los datos de operaciones aceptadas, los campos “CodResult” y “Texto”
no aportan nada (siempre serían “0;Operación aceptada”). Por ese motivo los eliminamos y ponemos
en su lugar la fecha y hora que es un dato que sí aporta información útil.
El servicio siempre manda una última trama en la que no hay datos, solo [STX][ETX]. Esa trama es la
que indica que ya se han enviado todas las transacciones y no hay más datos por enviar. Al recibir esa
trama, el programa de gestión debe confirmarla con el correspondiente ACK y cerrar el socket, porque
el diálogo ya ha concluido.
En caso de que el listado de transacciones esté vacío (no hay ninguna operación), la primera trama de
respuesta del servicio será [STX][ETX], indicando así que no hay transacciones que cumplan con los
datos de la consulta.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 32 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
El segundo caso en el que se utiliza un diálogo extendido es en la venta TNA, que como ya hemos
descrito anteriormente se utiliza en terminales no atendidos y también en los casos en los que el
importe a cobrar no se puede determinar hasta que se ha leído la tarjeta. El diálogo aquí es el
siguiente:
---> [STX]Cliente;Tienda;Tpv;Operario;Ticket;44[ETX]
<--- [STX]CodResult;Texto[;BIN][ETX]
---> [STX]Importe;Banco;PagoAplazado[ETX]
<--- [STX]CodResult;Texto[DatosAdicionales][ETX]
---> [STX]ACK[ETX]
La petición inicial del programa de gestión al servicio ya se ha descrito en puntos anteriores. La
respuesta del servicio a esa petición es una trama con el formato estándar: un código de respuesta, un
texto asociado y unos datos adicionales. Si ‘CodResult’ es 0, la transacción se está procesando
correctamente: el servicio ha activado el Pin-Pad, el cliente ha introducido su tarjeta y en el campo BIN
se informa al programa de gestión de la tarjeta leída. Lo que debe hacer el programa de gestión es
enviar la segunda trama de petición para informar al servicio de los datos necesarios para completar la
venta (Importe, Banco y PagoAplazado, campos ya descritos en el punto 5.1). A partir de aquí el
diálogo es idéntico al utilizado en la venta normal. La respuesta del servicio es la misma que la descrita
en el punto 5.2 para la venta (tipo 1) y el programa de gestión debe aceptar esa respuesta con el
correspondiente ACK para confirmar la transacción.
Si el campo ‘CodResult’ en la primera respuesta del servicio es distinto de 0, la tarjeta no se ha podido
leer y la transacción no se puede llevar a cabo, por lo que no tiene sentido continuar el proceso. En
ese caso, el campo BIN no está presente en la respuesta y el servicio no espera la segunda trama de
petición del programa de gestión sino el ACK final. El dialogo quedaría por tanto reducido a un diálogo
estándar de tres tramas: petición-respuesta_error-ack.
El tercer y último caso en el que se utiliza un diálogo extendido es en la venta DCC. Igual que en la
venta TNA se utiliza un diálogo con 5 tramas que puede quedar reducido a tres en ciertas condiciones.
Estas son las tramas utilizadas.
---> [STX]Cliente;Tienda;Tpv;Operario;Ticket;46;Importe;Banco;PagoAplazado[ETX]
<--- [STX]198;INFO DCC;DatosAdicionalesDCC[ETX]
---> [STX]ACK_DCC[ETX]
<--- [STX]CodResult;Texto[;Moneda][DatosAdicionales][ETX]
---> [STX]ACK[ETX]
La petición inicial del programa de gestión al servicio ya se ha descrito en puntos anteriores. La
respuesta a esa petición será normalmente una trama con información DCC en la que el servicio
informa al programa de gestión que la operación se puede realizar en divisa. Si es necesario, el
programa de gestión emitirá el ticket informativo DCC para entregar al cliente y a continuación enviará
la trama ‘ACK_DCC’ al servicio para que continúe el proceso. Una vez completada la transacción, el
servicio envía la trama de respuesta final, que en caso de estar activada la configuración contactless
será idéntica a la descrita en el punto 5.2 para la venta (tipo 1). Si no es así (no se ha activado
[CTLSRESP]), la respuesta generada difiere de la descrita en el punto 5.2 únicamente en el campo
‘Moneda’, que se añade en la posición indicada arriba porque la trama descrita en el punto 5.2 para
esta configuración no incluye dicho campo.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 33 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
También puede ocurrir que la tarjeta del cliente no admita la operativa DCC y en ese caso no hay
información que enviar al programa de gestión. En esa situación el dialogo se reduce a tres tramas
como el de la venta normal. El programa de gestión del punto de venta puede diferenciar estos dos
casos por el código de respuesta. Si envía la petición y recibe una respuesta con código 198, se trata
de una trama de información DCC y el dialogo es de 5 tramas. Si la respuesta que recibe tras enviar la
petición tiene cualquier otro valor distinto a 198, no se ha podido activar el proceso DCC y se trata de
un diálogo de 3 tramas.
La trama de información DCC tiene siempre el valor 198 seguido por el texto “INFO DCC” y a
continuación unos datos adicionales con la información DCC. Estos datos adicionales siguen la
codificación estándar de todas las tramas, siendo una serie de campos separados por ‘;’:
;Importe;ImporteFC;ExchangeRate;MarkUp;Commission;EntidadGestora
Todos ellos deben aparecer en el ticket informativo que se entrega al cliente cuando el Pin-Pad no
tiene capacidad para mostrar toda la información necesaria. Y también deben estar en el ticket final
que se entrega al cliente al completar el pago cuando éste ha seleccionado su moneda en lugar del
Euro, aplicando por tanto el DCC. En el próximo punto se pueden ver algunos tickets de ejemplo y a
continuación mostramos también una trama de ejemplo en la que se puede ver cómo envía el servicio
la información:
[STX]198;INFO DCC;EUR: 12,90;USD: 17,80;1,00 USD = 0,81557 EUR;3,00 %;0,00 %;CaixaBank[ETX]
La trama ACK_DCC es como el ACK normal pero añadiendo los 4 caracteres ASCII que completan el
texto “ACK_DCC”: el carácter subrayado, la letra ‘D’, la letra ‘C’ y de nuevo la letra ‘C’.
Comentar por último que en la trama de respuesta final, el campo ‘Moneda’ (cuyo formato ya se ha
descrito anteriormente) indica al programa de gestión cuál ha sido la elección del cliente. El texto
‘EUR’ indica que el pago se ha hecho en euros y por tanto no se ha aplicado DCC. Cualquier otro valor
en ese campo indica que se ha pagado en divisa y por tanto el ticket que se emite para el cliente debe
incluir toda la información relativa al proceso DCC.
6. Formato de los Tickets a Generar
En las transacciones de Venta, Devolución, Reserva/Confirmación y Recarga telefónica, el programa
de gestión del punto de venta debe generar un ticket para el cliente. Dicho ticket debe incluir la
información que el servicio envía en la trama de respuesta.
Excluyendo los campos ‘CodResult’, ‘Texto’ y algunos más que son simplemente información de
control o datos estadísticos para la aplicación, la mayor parte de los campos que el servicio manda en
la trama de respuesta deberían aparecer en el ticket que se entrega al cliente.
En el caso de las recargas telefónicas, no hay un control demasiado estricto. Pero en las operaciones
TEF, es extremadamente importante generar el ticket con toda la información necesaria. El formato
del ticket (la posición en la que aparece cada campo) no es importante, lo realmente importante es
que todos los datos necesarios aparezcan en él. De ello depende que ante una reclamación, la
operación se considere válida y el banco o la marca emisora de la tarjeta asuman su responsabilidad.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 34 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
A continuación mostramos varios tickets de ejemplo que contemplan las distintas operativas que el
servicio puede utilizar. En todos los casos vamos a mostrar siempre dos tickets: la copia para el cliente
y la copia para el establecimiento. La copia del cliente siempre se debe generar, mientras que la del
establecimiento solo es necesaria cuando el cliente tiene que firmar y el Pin-Pad utilizado no tiene
captura de firma.
El primer ejemplo es el caso más habitual: una venta normal realizada con una tarjeta chip. En este
caso, el ticket para el cliente tiene en primer lugar los datos de la compra (artículos vendidos, importe,
etc.) y a continuación los datos de la operación de pago. En el ticket para el establecimiento solo
mostramos los datos de la operación de pago y el texto “Operación con PIN, firma no necesaria”, ya
que la operación se ha validado con PIN.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 35 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
El segundo ejemplo es una operación con tarjeta contactless en la que el importe es inferior al “CVM
limit” y por ello el Pin-Pad no solicita al usuario que introduzca el PIN y tampoco debe pedírsele firma.
Por eso el texto que aparece es “Operación contactless, firma no necesaria”. También es importante
notar que en este ticket aparece el logo contactless. Esto es así porque así lo piden expresamente las
marcas internacionales (Visa, MasterCard, etc.): toda operación que se haga con una tarjeta de este
tipo debe llevar el logo correspondiente en el ticket. Por ese motivo se ha añadido el campo
“TipoLectura” en las nuevas tramas de respuesta del servicio, para que el programa de gestión del TPV
sepa si se ha utilizado una tarjeta de este tipo y en ese caso pueda incluir el logo correspondiente en el
ticket. De acuerdo a lo que se ha descrito en puntos anteriores, el logo debería aparecer siempre que
el campo “TipoLectura” tenga el valor 4 (tarjeta contactless) o 5 (móvil NFC)
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 36 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
El tercer ejemplo es un ticket pagado también con tarjeta chip pero en el que el cliente no ha tecleado
su PIN, bien porque tiene configurada su tarjeta así o bien porque ha realizado un “bypass” dándole al
OK varias veces sin teclear su PIN. En este caso, la respuesta del servicio incluirá los valores apropiados
para indicar al programa de gestión del TPV que debe pedir la firma del cliente (si no se ha capturado
ya en el propio Pin-Pad).
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 37 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Y a continuación mostramos otro ticket en el que se ha utilizado un tipo especial de tarjeta contactless
que funciona igual que una tarjeta de banda magnética. La tarjeta se identifica como contactless y por
eso aparece el logo correspondiente en el ticket. Pero al ser equivalente a una tarjeta de banda, no
hay campos AID, LBL ni ARC y tampoco aparece el nombre del titular porque la tarjeta no se lo ha
enviado al terminal.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 38 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
Por último, mostramos también los tickets generados en un par de operaciones DCC. La primera se ha
hecho con una tarjeta visa de banda magnética asociada a una cuenta en Dólares. La segunda es una
MasterCard con chip ligada a una cuenta en Libras. En ambos casos hay un primer ticket informativo
que siempre tiene el mismo formato:
Los datos de ese ticket salen de la primera trama de respuesta que el servicio manda al programa de
gestión del punto de venta en la operativa DCC, tal como se ha descrito en el punto 5.4. Los textos en
inglés deben aparecer exactamente igual, no se pueden cambiar porque son los que las marcas (Visa y
MasterCard) han aprobado para esta operativa.
Si la operación se realiza finalmente en euros, los tickets a generar son los que ya hemos visto antes.
Al no aplicarse el proceso DCC no hay nada más que mostrar en el ticket del cliente o del comercio.
Pero si la operación se realiza en divisa, entonces los tickets para cliente y establecimiento deben
tener el formato que mostramos a continuación.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 39 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
En el ticket que se lleva el cliente se debe mostrar el importe que finalmente ha pagado en su
moneda, el equivalente en euros y la misma información del cambio que se ha mostrado en el ticket
informativo anterior. Además deben aparecer los textos ‘Disclosure’ que como se puede ver son
distintos según el tipo de tarjeta (Visa o Mastercard).
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 40 (41)
Pasarela de Pagos – Payment Gateway
Avda. La Industria 4  NATEA Business Park  28108 ALCOBENDAS (Madrid)  902-305 308 – 91-490 01 50
El ticket que se queda el comercio incluye la misma información que el del cliente, pero en este caso
incluye un cuadro de firma que siempre debe estar presente, aunque la venta se haya validado con
PIN. Esa firma es la que garantiza a Visa y MasterCard que el cliente acepta los ‘Disclaimer’ y textos
legales que aparecen en el ticket.
12/05/2015
Protocolo de Conexión C le ar O N E versión 1.5
Página 41 (41)