Diferencia entre revisiones de «SIU-Sanaviron-Quilmes/FAQ/Pendiente»

De SIU
Saltar a: navegación, buscar
Línea 1: Línea 1:
 +
= No se actualiza estado en ventas =
 +
 
== ¿Que sucede? ==
 
== ¿Que sucede? ==
 
Se realiza el cobro correctamente por MercadoPago pero la cobranza figura en estado Pendiente.  
 
Se realiza el cobro correctamente por MercadoPago pero la cobranza figura en estado Pendiente.  

Revisión del 16:15 16 may 2019

No se actualiza estado en ventas

¿Que sucede?

Se realiza el cobro correctamente por MercadoPago pero la cobranza figura en estado Pendiente.

Esto puede aplicar también a otros agentes de cobranza como PayPerTic, etc.

Contexto

El entorno de testing funciona en un ambiente dockerizado donde las máquinas que corren los distintos sistemas no cuentan con una IP pública donde recibir notificaciones.

Para esto existe un archivo simple php que funciona como nexo entre los agentes de cobranza y la máquina docker en una red privada.

¿Qué verificar?

Primero

Verificar las urls en GCO.

Las urls del dispatcher se configuran en el paso 4 de la documentación de instalación en testing.

Se setean el archivo instalacion.env y se replican en el archivo config/config.ini del proyecto GCO.

Si por algún motivo se salteo el paso de configuración y no se desea comenzar la instalación desde el primer paso, se pueden agregar directamente en config/config.ini del proyecto GCO.

También verificar credenciales del gestor de pago.

A modo de ejemplo:
back_url = "http://hostpublico.unx.edu.ar/dispatcher_back_mp.php?sender=Usuario|192.168.0.12:4003|"
url_notificaciones = "http://hostpublico.unx.edu.ar/dispatcher_notificacion.php?sender=Usuario|192.168.0.12:4003|"
client_id = "6068000011112200"
client_secret = "xxxxXXXXxxxxXXXXXXXXxxxxXXXXX"

Segundo

Una vez configurado correctamente, verificar que el agente de cobranza logre comunicarse con este dispatcher.

Al recibir una notificación se escribe una linea a modo de log con el fecha, id de merchant, payment u otro.

El nombre del archivo de log por default es: mp_log.txt

También se escribe el host donde se va a redirigir esta notificación. El host ( ip : puerto ) debería ser la del gestor de cobro ( GCO ).

A modo de ejemplo:
SENDER NAME: Usuario | SENDER IP: 192.168.0.12:4003 | Fecha: 2019-05-01 12:23:34 - Topic: merchant_order - ID: 1100888282
En este instante deberíamos tener validado que el gestor de pago recibe correctamente las notificaciones.

Caso contrario se debería revisar cuestiones de conectividad, configuración de servidor http, etc.

Tercero

Verificar que se puede comunicar este servidor público con las máquinas docker de los distintos sistemas.

Para validar comunicación con el sistema SQ Académico:
curl -utoba http://192.168.0.1:4002/sq_academico/rest/articulos
Acá reemplazar la ip:puerto con la correspondiente al sistema SQ Académico.

El password por defecto para el usuario toba es toba123*-a

Esto debería devolver un json con el listado de artículos en el módulo académico.

Para validar comunicación con el sistema GCO.
curl -X POST -d '{"tipo_documento":1,"numero_documento":"30123456"}' -usq_academico http://192.168.0.1:4003/sq_pagos_backend/generar_token
Acá reemplazar la ip:puerto con la correspondiente al sistema GCO.

El password por defecto para el usuario sq_academico es 123456

Esto debería devolver un json con un nuevo token.

En este instante deberíamos tener validado que el servidor público que recibe las notificaciones se puede comunicar correctamente con los módulos en ambiente dockerizado que se encuentran en una red privada.

Caso contrario se debería revisar cuestiones de conectividad, configuración de servidor http, etc.

Cuarto

Verificar que las credenciales generadas el gestor de pagos sean válidas, eso se realiza desde cada gestor de pagos.