Índice
Sección: Menú Configuración > Global Payments
Preguntas Frecuentes
Introducción
Global Payments Inc. es una empresa estadounidense que proporciona tecnología y servicios de pago a comerciantes, emisores y consumidores. La empresa procesa los pagos realizados a través de tarjetas de crédito, tarjetas de débito y pagos digitales y sin contacto.
Configuración
Sección: Menú Configuración > Global Payments > Configuración
Seleccionar el botón Save
Transacciones
Sección: Menú Configuración > Global Payments > Transacciones
Para consultar los movimientos que se han realizado a través de Global Payments:
ID: es el ID de la línea de movimiento.
Tipo: hay 2 tipos: Pago o Reembolso.
Venta: es el ID de la venta. A través de este ID, puedes consultar las líneas de venta en el TPV.
Ticket: es el ID del ticket. A través de este ID, puedes consultar las líneas de ticket.
Éxito: hay 2 opciones: SI, un pago ha sido procesado correctamente. NO, en caso contrario. Dirígete a la columna “Error” para ver el mensaje.
Código de respuesta
ID Orden
Transacción
Petición
Respuesta
Petición 2
Respuesta 2
Error: Si tiene cualquier duda sobre el error que se visualiza, ponte en contacto con Soporte.
Hacer una devolución/anulación de una venta con Global Payments
No se pueden devolver cantidades parciales con Global Payments y no se puede hacer ventas en negativo. Es decir, puedes cancelar o Anular un cobro, pero no vender un producto en el TPV con el precio en negativo y la forma de pago de Global Payments.
Tienes varias opciones:
Devolver todo y volver a cobrar:
Anular el cobro/ticket (NO anular la línea de venta). El datáfono de Global Payments te pedirá pasar la tarjeta del cliente para hacer la devolución.
NOTA: Anular el cobro y seguir con la línea de venta, no modifica los informes de Producción.
Añadir una o tantas líneas nuevas en negativo necesites con el mismo precio. En caso necesario, puedes modificar el precio de cada línea de venta.
El total de todas las líneas será 0€ (Positivo + Negativo = 0€), selecciona Finalizar y quedará pagada, sin deuda al cliente (con la franja verde)
Hacer una venta en negativo:
Añades una nueva línea de venta en el TPV en negativo
Finalizar con otra forma de pago (Tarjeta, Efectivo, Transferencia,...)
Realizar un reembolso manual en la web de Global Payments (o Redsys, según contratado), o contactar con el soporte técnico de Global Payments para que ellos hagan el reembolso
Soluciones integradas LANE-7000
PASOS PREVIOS - LOS ELEMENTOS NECESARIOS
Para la integración necesitaremos comprobar que disponemos de algunos elementos que se listan a continuación:
Necesidades del equipo
Requisitos de red
Software proporcionado
INSTALACIÓN DE SOFTWARE
El funcionamiento correcto requiere la instalación del software específico del producto tal y como se detalla a continuación:
Se proporcionará el archivo CGP.POS.Framework.WebAPI_V1.x.xx.zip.
Este archivo incluye el siguiente desglose de archivos:
Todo lo necesario se instalará ejecutando el archivo “runner.bat”. Será necesario ejecutarlo como administrador. Este mismo archivo identificará la versión más adecuada para el pc en el que estamos instalando.
DESGLOSE Y USO DE LAS HERRAMIENTAS
Una vez completada la instalación podremos revisar el funcionamiento correcto del pinpad accediendo a la siguiente dirección:
Aquí nos encontraremos con la siguiente pantalla:
Encontraremos tres puntos de operación disponibles:
Authorisation POST Describe la operación de cobro normal. Enviará un pago al pinpad para empezar la operación de pago. Esto inicia una transacción asíncrona con el pinpad, que se ejecuta en segundo plano en el Framework. Ejecutándolo de nuevo, antes de que finalice la transacción nos devuelve su estado actualizado.
Rebate POST Deshacer una operación de cobro anterior, finaliza el pago, y devuelve el importe al pinpad. Ejecutándolo de nuevo, antes de que finalice la transacción nos devuelve su estado actualizado.
Complete POST La transacción finaliza cuando el ticket es entregado al cliente. Dado que este paso puede ser completado por una impresora externa, este final es requerido para confirmar la transacción.
De esta forma, el flujo normal de trabajo sería:
POST /api/v1/Authorisation => Inicia autorización
POST /api/v1/Authorisation => Comprueba estado autorización
Espera hasta que la transacción ha finalizado (la tarjeta de crédito ha sido enviada al Pinpad y se ha recibido una respuesta online y contestado al Framework.) Para saber si ha finalizado hay que volver a comprobar la autorización, incluso después de que el Pinpad haya aceptado la transacción. Puede tomar unos segundos para informar si la transacción ha sido procesada.
POST /api/v1/Complete => complete la transacción (o la finaliza si el ticket no se ha impreso)
Parámetros
Parámetros de solicitud
orderID: identificador usado por la aplicación para encontrar la transacción en el futuro, como la acción completa, lo cual devuelve la transacción completa.
Amount: cantidad que se cobrará, con decimales, cobrado en una moneda aceptada por el banco de la tarjeta
Currency: moneda aceptada por el banco de la tarjeta, formado por 3 letras. ISO-4217.
Payer/card reference: token de hasta 50 caracteres que identifican al pagador/tarjeta, para que así la información no se tenga que recoger de nuevo. Para la primera transacción, este campo, estará vacío.
Tip: importe con decimales que se dejará como propina.
PartnerTransID: ID transacción completa
Parámetros de respuesta
Tokens: referencia de pagador/tarjeta para usar en futuras transacciones.
CurrencyDCC: moneda aceptada por el vendedor (Dynamic Currency Conversion)
AmountDCC: Cantidad de moneda en valores decimales para la moneda intercambiada DCC.
Exchange: DCC tipo de cambio aplicado.
TimeStamp: Fecha y hora en que se realizó la transacción.
TransactionId: ID de transacción de terminal. Se devuelve después de que una transacción se haya procesado de principio a fin. Referencia requerida en la operación de reembolso.
ResponseCode: error de terminal / código de éxito.
Status: Descripción del texto del código anterior.
IsOk: indica si la transacción se ha completado con éxito o no. Regreso de diferentes operaciones. Diferentes códigos de respuesta y una transacción pueden resultar correctos con diferentes rutas.
PartnerTransId: ID de transacción de socio de Alipay completo.
AlipayTransId: Alipay Transaction Id devuelto por el marco.
Código de respuesta de procesos
Se define por tres números. El primero indica la categoría de nivel superior:
0XX Código recibido de la Autorización o Rebate del pago. Lo devuelve el Pinpad después de que empiece la operación, antes de completarse.
1XX El Pinpad no ha podido procesar la transacción enviada por el Framework correctamente y tiene un problema interno.
2XX Respuesta del proceso de la transacción. Errores que pueden suceder en el Framework como resultado del flujo de información en la autorización o devolución.
Sin Código quiere decir que hay un problema básico con la conectividad del puente al dispositivo:
Dispositivo active desconectado.
PCL no se puede iniciar
Hay un error intentando crear una conexión puente.
Sin dispositivo active
Más de un dispositivo conectado. (Solo si hay uno active)
Activar el dispositivo require permisos de administrador.
No se pudo activar el dispositivo
Respuesta del Proceso (2XX)
Desde que el estado de la transacción sea aceptado por las llamadas para la autorización o devolución
La información detallada de los códigos 2XX es necesaria:
200 Una nueva transacción ha comenzado, el comando es enviado al Pinpad. Si no hay respuesta por parte del PinPad ni mensaje de error, esto es una respuesta por defecto.
Si el Pinpad no muestra el pago tienes que esperar a que se acabe el tiempo, de otra forma si se cancela en el Pinpad se enviara una respuesta al framework para cancelar la transacción
210 Las transacciones están definidas por el framework por orden de llegada Si no hay ninguna transacción ocurriendo en el momento, pero la autorización o devolución ha sido realizada por otro envió el framework le devolverá lo siguiente: Código indicando que no ha sido posible empezar una nueva transacción hasta que la anterior acabe (por error o por finalización de la transacción).
211 La transacción que se ha solicitado para ser finalizada no está siendo ejecutada.
212 La transacción que se ha solicitado para ser finalizada no estaba en su estado correcto. Está siendo procesada por el Pinpad.
213 La transacción ha sido enviada para finalizarla mientras que el Pinpad da respuesta. Tiempo agotado (configurar los argumentos WaitMaxAttemps y WaitSleepTime). Esto no canela la transacción, llama para comprobar el estado de la transacción.
220 El PCL no pudo encontrar ningún dispositivo activo.
221 Tiempo agotado mientras se ejecutaba la transacción. La conexión con el Pinpad es correcta, el mensaje fue enviado pero la respuesta tomo demasiado tiempo. (se puede configurar con el argumento CommandTimeout)
230 La transacción no pudo imprimir el ticket o ha sido cancelado por la caja registradora. (Completar el terminal llamado con un ticket imprimido falso).
240 El servicio del framework ha sido reiniciado y no puede continuar con la transacción previa
Ejemplos
Códigos de resultados
00 Código genérico para operaciones completadas con algún error.
01 Reservado.
02 tarjeta errónea (formato de ISO erróneos, checkear Luhn).
005 tarjeta no válida .
06 Operación cancelada antes de intentar conexión online (por temas EMV, etc.) En las operaciones EMV los tags de Emv son necesarios analizar por la denegación de la transacción será enviada como datos a la impresora.
07 Transacción no finalizada correctamente en el entorno online.
008 Error en el formato de mensaje recibido por la caja registradora.
009 Error con la moneda
011 Transacción cancelada en el Pinpad por el usuario.
012 Transacción aprobada por fallback.
013 Pinpad no inicializada.
020 Pinpad sin lector.
060 Ventas con DCC.
090 Transacción aceptada por banda magnética.
091 EMV transacción aceptada online.
092 Contactless Transacción aceptada online.
096 Transacción aceptada por la banda magnética offline.
097 EMV transacción aceptada sin ninguna llamada online.
098 Transacción Contactless aceptada offline.
099 Código genérico por las operaciones realizadas con éxito.
104 XML formato Error. r
105 Error interno. reques
107 Datos obligatorios perdidos en un mensaje XML.
108 Terminal ocupado con otra transacción.
109 Error desconocido.
200 Procesando error
210 Pinpad ocupado en otra transacción
211 Transacción no pudo ser finalizadas porque no fue encontrada
212 La transacción no pudo ser finalizada porque estaba en un estado desconocido
213 Transacción tomo mucho tiempo en procesar la confirmación ACK
220 Ha habido un problema con la conexión del Pinpad
221 Transacción cancelada debido a una acción con el Pinpad que tomo mucho tiempo en completar
230 Transacción cancelada por el solicitante
240 El servidor ha sido reiniciado y no pudo activar la transacción
Códigos de Framework
A través de la documentación prevista, podrán comprobar las transacciones según los siguientes códigos:
PASO DE LA INTEGRACIÓN
Un sistema integrado permite al comercio realizar transacciones sin necesidad de entrar en contacto con el terminal. Los pasos que necesarios para el procesamiento de una operación son los siguientes:
El comercio indicará en el software de caja el tipo de transacción a realizar (venta, devolución, preautorización, etc.), los detalles relacionados (importe, descuentos, etc.) y la modalidad de cobro con tarjeta.
Una vez incorporadas estos detalles, el software de caja los transmitirá al pin pad junto con otros datos de la operación (fecha y hora de la operación, número de comercio, moneda, etc.)
Una vez recibido el mensaje, el pin pad se activará indicando al cliente las instrucciones para realizar la transacción (acerque tarjeta, inserte tarjeta, introduzca pin, etc.) y enviará la operación a procesar.
Después del procesamiento, el pin pad recibirá una un resultado: la transacción habrá sido aceptada o denegada.
BATERÍA DE PRUEBAS
Para completar la integración de su solución de pago TPVPC Comercia 2.0 con su software de caja, recomendamos completar el proceso de validación de integración para terminales TPV PC.
Dicho proceso consiste en una batería de pruebas diseñadas para confirmar que la solución de pago queda lista para su uso en producción, y adecuación a la normativa vigente como aceptación de tarjetas de distinta tecnología, interoperabilidad y usabilidad de la misma, así como la validación de los recibos emitidos.
A continuación, le proponemos una batería de pruebas que agradecemos que nos haga llegar a nuestra dirección de correo de Soporte para validar por nuestro lado.
Versión PINPAD:
Versión Software de Caja:
Además de esto, se deberán adjuntar capturas de pantalla de los tickets generados indicando cada una de las transacciones realizadas.
Preguntas Frecuentes
Problemas para acceder a SWAGGER .
A- Se le facilita de nuevo y accede sin problema. Se contacta con el cliente para confirmar acceso al SWAGGER facilitado por segunda vez. Integración de software 15
Visualización de las transacciones. Cliente tiene dudas acerca de si podrá visualizar las transacciones realizadas una vez integrado el PSP.
A- Informamos al cliente que esta operación se configura en su propio software de caja.
Tokenización. Cliente solicita la posibilidad de integrar “la tokenización” en el PSP.
A- Se le informa que por el momento no es posible (esto estará disponible a partir del 2Q/3Q)
Cliente solicita soportes físicos para los TPV-PC (Pole)
A- Gestionamos con Comercia.
Ayuda a la integración
¿CÓMO OBTENGO LA CLAVE SHA256 DE MI TPV VIRTUAL PARA ENTORNO REAL?
IMPORTANTE: LAS CLAVES SON ÚNICAS PARA CADA TERMINAL, Y DIFERENTES DEPENDIENDO DE SI SON PARA ENTORNO DE PRUEBAS O ENTORNO REAL.
La clave SHA-256 es un código alfanumérico imprescindible para poder realizar operaciones a través de su TPV virtual, y es diferente según el terminal y el entorno. Por ejemplo, en caso de disponer de los terminales 1 y 2, el n.º total de claves disponibles será 4, una por cada terminal en entorno de pruebas, y otra diferente por cada terminal en entorno real.
Por motivos de seguridad, la clave SHA-256 para la firma de operaciones no se facilita por correo electrónico, sino que se obtiene directamente desde la página web de Canales.
Para obtener la clave correcta, antes de poder operar en entorno real, siga los pasos indicados:
1.- Acceda al módulo de administración de su TPV virtual en entorno real. Podrá realizarlo a través de una de las siguientes direcciones:
2.- Datos de acceso Usuario: facilitado en el correo de alta en real. Password: Haga click sobre “¿Ha olvidado su contraseña?” y recibirá la contraseña para acceder al panel de administración en el correo electrónico que tenga autorizado.
3.- Una vez dentro del portal de canales, en el menú que se despliega en el lateral izquierdo, haga clic en Administración (icono del maletín).
4.- Seleccione la opción Comercio en el menú izquierdo.
5.- En la ventana que se la muestra, haga clic en el botón Buscar.
6.- Aparecerá un listado de los TPV virtuales de su comercio. Haga clic en el botón Detalles ( icono del ojo) del terminal para el cual quiere obtener la clave SHA-256
7.- Se le mostrará la configuración del TPV virtual. En la sección “Datos de configuración” haga clic en el botón Ver clave.
8.- Aparecerá una ventana emergente solicitando una contraseña. Introduzca la clave con la cual ha iniciado sesión en Canales.
9.- En la ventana emergente se mostrará durante 10 segundos la clave secreta de cifrado. Tendrá acceso a dos claves, la SHA-1 (corta) arriba y la SHA-256 (larga) debajo.
10.- Copie la clave SHA-256 y guárdela en un lugar seguro para su posterior uso. Verifique que copia la clave entera, sin incluir espacios en blanco al principio o al final.
ME APARECE UN ERROR CUANDO INTENTO REALIZAR UN PAGO
Si, tras configurar los datos de su TPV virtual en su pasarela, le aparece un error como el mostrado en el momento de acceder a la pasarela de pago de Redsys:
Realice los siguientes pasos para localizar el motivo del error:
1. Si no tiene acceso a la pantalla de error realice un nuevo pedido hasta llegar a dicha pantalla de error.
2. Una vez visualice el mensaje Error de datos enviados. Contacte con su comercio, haremos clic con el botón derecho sobre la página de error para mostrar el menú contextual, y seleccionaremos la opción Ver código fuente.
3. En el código fuente listado, contamos hasta la línea 36, la cual comenzará por una cadena de texto con formato <!--SIS0xxx:-->
4. Consulte el motivo del código SIS0xxx obtenido y su posible solución en la lista facilitada en Anexo 1 - Errores SIS0xxx comunes
5. En caso de no encontrarse definido en el Anexo 1, o necesitar información adicional, envíenos un correo y le informaremos de su causa.
LOS PEDIDOS NO SE ACTUALIZAN EN MI PLATAFORMA
Si el terminal tiene activado el envío de notificaciones en su configuración, podemos listarlas y verificar su correcto envío y recepción por parte de la plataforma del comercio. Todas las operaciones que sean finalizadas, independientemente de si han sido autorizadas o denegadas, generarán notificación conforme a la configuración del terminal. Las operaciones que no hayan sido finalizadas no generan notificación, por lo que no aparecerán en el listado, a diferencia de la consulta de operaciones.
Para realizar una consulta de notificaciones realizamos los siguientes pasos:
1. Acceda a la web de gestión de canales a través de una de las siguientes direcciones: https:// canales .redsys.es/lacaixa/ para usuarios de entorno de producción. https://sis-t.redsys.es:25443/canales/ para usuarios de entorno de pruebas.
2. Introduzca su usuario y contraseña de acceso.
3. Una vez dentro del portal de canales, en el menú que se despliega en el lateral izquierdo, haga clic en Administración (icono del maletín).
4. Seleccione Notificaciones para configurar el listado a generar.
5. En las pantalla de configuración, podrá definir los siguientes parámetros:
N.º de terminal: si necesita filtrar el listado de notificaciones por terminal, introduzca el n.º del mismo. Si deja vacio el campo se mostrarán las notificaciones de todos sus terminales en orden cronológico.
Número de pedido: permite filtrar las notificaciones enviadas sobre un mismo n.º de pedido (autorizaciones, pre-autorizaciones, devoluciones, pagos sucesivos, etc). En caso de que no le muestre resultados, revise las fechas configuradas en el periodo.
Tipo de notificación: nos permite filtrar y acotar la búsqueda basándose en varios criterios. Los tipos de notificación disponibles son:
HTTP para listar únicamente las notificaciones enviadas por POST o GET.
E-Mail para listar únicamente las notificaciones enviadas por correo a la cuenta introducida en la configuración del terminal.
SOAP para listar únicamente las notificaciones SOAP.
• Resultado: filtra por el resultado de la entrega de la notificación.
Todos: muestra todas las notificaciones, hayan sido o no entregadas correctamente.
Correcto: muestra las notificaciones que han sido correctamente entregadas.
Incorrecto: muestra las notificaciones que no han podido ser correctamente entregadas.
Periodo – Hora inicio – Hora fin: nos permite acotar la búsqueda a las fechas y horas indicadas. El plazo máximo para consultar notificaciones es desde 30 hasta 90 días.
6. Para modificar el n.º de resultados mostrados por página en el listado, dispone de un control en la parte superior izquierda del mismo que permite mostrar hasta un máximo de 500 notificaciones por página.
7. Con la consulta de notificaciones configurada según sus necesidades, haga clic en el botón “Filtrar”. En la parte inferior de la pantalla se mostrará el resultado de la búsqueda.
8. En el listado de notificaciones puede observar las siguientes columnas:
Terminal: n.º de terminal en el que ha sido recibida y gestionada la operación.
Fecha: fecha y hora en la que Redsys ha enviado la notificación a su plataforma.
Tipo Oper: tipo de operación (Autorización, Pre-autorización, Devolución, etc.).
Nº Pedido: n.º de pedido recibido desde su plataforma con la operación.
Tipo de Notif: especifica el canal por el cual ha sido enviada la notificación. Los posibles valores son HTTP, e-mail y SOAP.
Código Respuesta. Indica el resultado de la operación:
Operaciones aceptadas: código de respuesta comprendido entre 0000 y 0099.
Operaciones denegadas: código de respuesta igual o superior a 0100.
Resultado: indica si la notificación ha sido entregada correctamente a su plataforma. Los posibles valores son “Correcto” y “Error”
Destino / Detalle.
Notificaciones HTTP: especifica la url a la que ha sido enviada la notificación.
Si la notificación ha sido aceptada por su plataforma, verá el código “200” debajo de la URL en la que ha sido entregada.
Si la notificación no ha podido ser entregada a su plataforma, se mostrará un error especificando el motivo. Puede consultar el motivo en el Anexo 2 – Códigos de error HTTP comunes en notificaciones
Notificaciones E-Mail: especifica la dirección de correo a la que ha sido enviada la notificación.
Si la notificación ha sido aceptada por el servidor de correo, verá el código OK bajo la dirección.
Si la notificación no ha sido aceptada por el servidor de correo, se mostrará un error especificando el motivo.
Opciones: mediante el botón Detalles (el icono de un ojo) permite visualizar en el navegador la notificación generada en cada operación.
Anexo 1 - Errores SIS0XXX comunes
A continuación adjuntamos un listado con los errores más comunes, y su posible solución:
SIS0007
Significado: Error al desmontar el XML de entrada.
Causa: el sistema no ha podido obtener los parámetros de la operación enviadoa al TPV virtual.
Posibles soluciones:
Plataformas modulares (PrestaShop, WooCommerce, Magento, Virtuemart, etc.):
La plataforma del comercio usa un tema modificado que genera problemas con el conector para la pasarela de pago.
Solución: desactive el tema modificado y activar el tema por defecto mientras localizar el error.
La plataforma del comercio no dispone de un conector con la pasarela de pago actualizado.
Solución: instale un conector con la pasarela de pago compatible con firma SHA-256.
Todas las plataformas:
El JSON generado contiene el carácter %, el cual genera un conflicto en el proceso de codificación, creando una cadena en Base64 erronea a partir de dicho carácter.
Solución: Elimine el carácter % de los nombre de los productos o del comercio.
La petición enviada no contiene los parámetros dentro de un JSON codificado en Base64.
Solución: en caso de desarrollos a medida, verifique que los parámetros son enviados dentro de un JSON codificado en Base64 al sistema.
SIS0022 – SIS0023
Significado: Error de formato en Ds_Merchant_TransactionType
Causa: se está enviando el campo Ds_Merchant_TransactionType con un valor no válido o vacío.
Posibles soluciones:
Plataformas modulares (PrestaShop, WooCommerce, Magento, Virtuemart, etc.):
Revise que el “Tipo de transacción” o “Transaction Type” configurado en el módulo de la pasarela de pago sea 0 (Cero).
Todas las plataformas:
Verifique que en el campo Ds_Merchant_TransactionType se envía un valor permitido según la guía de integración y en formato 000.
SIS0026
Significado: No existe el comercio / terminal enviado en SIS
Causa: no existe el n.º de terminal para el n.º de comercio en el entorno al que se ha enviado la operación. Puede producirse al enviar operaciones al entorno real sin haber superado la validación de la web del comercio por parte de CaixaBank.
Posibles soluciones:
Verifique que el n.º de terminal y n.º de comercio son correctos.
Verifique el entorno al cual se están enviando las operaciones en la configuración del módulo (consultar Anexo 3 – Entornos de Redsys).
En caso de no haber solicitado el pase a real, envie correo a caixabank@necomplus.es indicando el n.º de comercio, para poder realizar la validación de su web y alta en entorno real.
SIS0028
Significado: Error Comercio / terminal está dado de baja
Causa: El n.º de terminal indicado está dado de baja en el n.º de comercio indicado.
Posible solución: verifique que el terminal configurado está activo en el comercio indicado. Puede realizar una consulta del estado de su terminal a través de la web de Canales. En caso de aparecer como dado de baja, podrá consultar el motivo en su oficina de CaixaBank
SIS0042
Significado: La firma enviada no es correcta
Causa: la firma generada y enviada por su plataforma con las operaciones no es correcta. La firma se genera a partir de una clave SHA256 única para su terminal y el entorno al cual están siendo enviadas las operaciones. La clave SHA256 se puede obtener a través de la web de Canales.
Posibles soluciones:
Verifique que la clave configurada para la generación de la firma SHA256 es la correcta para el entorno al que envía las operaciones (pruebas – real) (consultar Anexo 3 – Entornos de Redsys).
Verifique que la clave configurada para la generación de la firma SHA256 es la correcta para el n.º de terminal.
SIS0075 – SIS0076 – SIS0077
Significado: el Ds_Merchant_Order tiene menos de 4 posiciones o más de 12 (Para algunas operativas el límite es 10 en lugar de 12)
Causa: El n.º de pedido generado por su plataforma y enviado con las operaciones no reúne los requisitos de Redsys.
Posible solución: Verifique que el n.º de pedido generado por su plataforma para el parámetro Ds_Merchant_Order cumpla las siguientes reglas:
Tiene un mínimo de 4 dígitos y un máximo de 12.
Los 4 primeros dígitos son numéricos.
Sólo se utilizan dígitos alfanuméricos (A-Z, a-z, 0-9).
SIS0431
Significado: Error del objeto JSON que se envía codificado en el parámetro Ds_MerchantParameters
Causa: La inclusión de caracteres especiales como, por ejemplo, el símbolo del porcentaje (%) en el nombre del comercio o de los artículos, provocara una codificación en Base64 erronea del JSON.
Posible solución: Revise si se está incluyendo caractéres especiales en alguno de los parámetros enviados dentro del JSON, como el nombre del comercio, nombre de los artículos, URL OK o URL KO, etc.
Anexo 2 – Códigos de error HTTP comunes en notificaciones
HTTP 403
Significado: URL con acceso prohibido.
Causa: la URL enviada en el parámetro Ds_Merchant_MerchantURL tiene el acceso restringido por permisos del servidor web donde está alojada.
Posibles soluciones:
Plataformas modulares (PrestaShop, WooCommerce, Magento, Virtuemart, etc.):
Las plataformas modulares pueden denegar el acceso a la URL de entrega de notificaciones si se encuentran en modo “mantenimiento” o “cerrada”.
Solución: desactivar el modo “mantenimiento” o abrir la web para que la URL de entrega de notificaciones sea accesible
Todas las plataformas:
Solución: revisar los permisos a nivel de hosting para que la URL de notificaciones enviada en el parámetro Ds_Merchant_MerchantURL sea accesible desde Internet.
HTTP 404
Significado: URL no encontrada.
Causa: la URL enviada en el parámetro Ds_Merchant_MerchantURL no existe.
Solución: verificar que la URL indicada en el parámetro Ds_Merchant_MerchantURL exista.
HTTP 500
Significado: Error interno del servidor.
Causa: la URL indicada en el parámetro Ds_Merchant_MerchantURL genera un error interno en el servidor web donde está alojada. Suele producirse por errores en la implementación de ASP, .NET o Java.
SIN CÓDIGO DE ERROR Y URL EN ROJO
Significado: No se ha podido resolver la URL
Causa: la URL enviada en el parámetro Ds_Merchant_MerchantURL apunta a un dominio no accesible desde Internet, o bien redirecciona a otra URL de forma automática.
Solución: verificar que la URL indicada en el parámetro Ds_Merchant_MerchantURL sea resolvible desde el exterior y que el dominio no realiza redirecciones automáticas a otro dominio.
Anexo 3 – Entornos de Redsys
Entorno Real o Producción (sis)
Es el entorno al que se envían las operaciones reales. Únicamente acepta tarjetas reales y operativas, por lo que si se intenta hacer una operación con una tarjeta no válida o con la tarjeta para pruebas, generará una denegación. Se identifica fácilmente porque contiene sis en la URL:
La URL a la que deben enviar las operaciones es:
https:// sis.redsys.es/sis/realizarPago ( la P mayúscula de Pago es imprescindible.)
La URL de acceso a canales es:
https:// sis.redsys.es/canales/lacaixa/ o https://canales.redsys.es/lacaixa/
Entorno de Pruebas o Test (sis-t)
Es el entorno al que se envían las operaciones para realizar pruebas durante la fase de integración del TPV virtual. Únicamente acepta la tarjeta para pruebas facilitada, por lo que si se intenta hacer una operación con una tarjeta real generará una denegación. Se identifica fácilmente porque contiene sis-t en la URL además del n.º de puerto 25443:
La URL a la que deben enviar las operaciones es:
https:// sis-t .redsys.es :25443/sis/realizarPago ( la P mayúscula de Pago es imprescindible.)
La URL de acceso a canales es:
https:// sis-t .redsys.es :25443/canales/
Entorno de Desarrollo e Integración (sis-d y sis-i)
Son entornos internos de Redsys que no están disponibles para los comercios. Las operaciones enviadas a dichos entornos siempre generarán error.
Las URL que contienen sis-i pertenecen al entorno de Integración.
Las URL que contienen sis-d pertenecen al entorno de Desarrollo.
Guía instalación Framework
Para su correcta instalación, por favor seguir los siguientes pasos:
PASOS PREVIOS
Para la integración necesitaremos comprobar que disponemos de algunos elementos que se listan a continuación:
El paquete de instalación contiene 8 archivos, los cuales son usados para instalar o desinstalar el Framework.
Verificación de ficheros del paquete
Verificación de versión instalada
DESINSTALACIÓN DEL FRAMEWORK
El funcionamiento correcto requiere la desinstalación del software específico tal y como se detalla a continuación:
● Abrir una ventana de “Símbolo del Sistema” o “Línea de comandos” (cmd.exe) con permisos de administración.
● Ejecutar un cambio de carpeta a la ruta donde esté el paquete de instalación: o Ejemplo: cd C:\DownLoad\FrameWork\
● Escribir dir y verificar que aparecen los ficheros del paquete tal y como se muestra en la imagen 03.
● Ejecutar el fichero uninstall.bat.
A partir de la versión 2.0.3.0 se actualiza también el PinPad.
Al finalizar la ejecución se ejecuta un reinicio.
Atención: Si se ejecuta este paquete de otra manera que no la descrita anteriormente no se ejecutará correctamente.
INSTALACIÓN DEL FRAMEWORK
El funcionamiento correcto requiere la instalación del software específico tal y como se detalla a continuación:
● Abrir una ventana de “Símbolo del Sistema” o “Línea de comandos” (cmd.exe) con permisos de administración.
● Ejecutar un cambio de carpeta a la ruta donde esté el paquete de instalación: o Ejemplo: cd C:\DownLoad\FrameWork\
● Escribir dir y verificar que aparecen los ficheros del paquete tal y como se muestra en la imagen 04.
● Ejecutar el fichero runner3.bat
Al finalizar la ejecución se ejecuta un reinicio.
Atención: Si se ejecuta este paquete de otra manera que no la descrita anteriormente no se ejecutará correctamente.
VERIFICACIÓN DE LA INSTALACIÓN
Para verificar la correcta instalación del Framework se deben ejecutar los siguientes pasos:
● Se debe abrir los Servicios de Windows y buscar por la existencia del servicio “Comercia GP Framework WebApi”, si está “Iniciado” y el tipo de inicio es “Automático”. Ver Imagen 05.
● Abrir el menú “Inicio” y buscar por “Configuración”. Imagen 06
● Abrir “Aplicaciones”. Imagen 07
● Buscar y seleccionar la Aplicación “CGP POS Framework” y verificar que aparece la versión correcta (2.0.3.X) Imagen 08
POSIBLES INCIDENCIAS
Si se encuentra el driver anterior es necesario ejecutar el uninstaller.bat antes de ejecutar el runner3.bat (bat de instalación).
Si esto no se hace la versión del driver no se va a actualizar correctamente. Pueden aparecer versiones adicionales de la librería PCL.
Esto no afecta la operativa, visto que se usará siempre la librería más reciente.
NOTAS:
Desinstalar el programa: CGP POS Framework desde el administrador de programas y características
En la carpeta raíz, ej para x64 C:\Program Files\CGP.POS.Framework, se encuentra un archivo origins.json, el cual contiene el listado de los origines permitidos para CORS. Tiene que aparecer la URL del club: https://"nombredelclub".golfmanager.com
Adicionar más, si es necesario, reiniciar el servicio o la máquina para actualizar los cambios.
Contacto de soporte comercia globalpay
Telf. 93 595 43 83 - 902 157 235 - 914 353 028
Horario: De 9h a 20h de Lunes a Viernes