Flujos

El servicio de Infonet Cobranzas solo tiene el Flujo 1

Movimiento de Fondos

En un Pedido de Pago, los movimientos de Fondos son realizados por Infonet, mediante la plataforma de ISO8583, de Cabal a Infonet. Esta es la definición, de lo que denominaremos en adelante como Pago.

En un Pedido de Reverso, los movimientos de Fondos son realizados por Infonet, mediante la plataforma de ISO8583, de Infonet a Cabal. Esta es la definición, de lo que denominaremos en adelante como Devolución.

Casos y Situaciones detectadas en las Pruebas

Pagos y Reversos

Se ha observado en los reversos lo siguiente:

1. El Sicoop envía el Pago.
2. IC solicita Autorización al jPos y Autorizador. 
3. El Sicoop aprobó el Pago. Este resultado el jPos y el Autorizador informan a IC.
4. IC realiza el Pago correspondiente.
5. El Sicoop envía el Reverso.
6. IC responde automáticamente como aprobado el reverso. El Sicoop marca de inmediato al reverso como aprobado.
7. IC remite el pedido de Reverso al jPos y Autorizador.
8. El Autorizador no encuentra el pedido de reverso como pendiente, por lo que rechaza el Reverso. La Devolución no podrá realizarse.
9. IC en teoría no realiza la Devolución.

Demora en Respuestas Simulado

Se activó la regla 41 para generar una demora de 45 segundos.

1. El Sicoop envía el Pedido de Pago.
2. IC remite el pedido de autorización de Pago al jPos y Autorizador.
3. El Autorizador procesa todas las reglas y encuentra el Pago como Aprobado por el Sicoop pero espera 45 segundos para continuar el proceso de Autorización.
4. IC rechaza la transacción e informa al Sicoop. El Sicoop procede a marcar la transacción de Pago como rechazada. Ya no está más como Pendiente.
5. El Autorizador al completar los 45 segundos, prosigue con el proceso de Autorización y busca el código de autorización del Pago Pendiente pero ya no lo encuentra y retorna cero como código de Autorización debido al punto 4.
6. IC envía el Reverso.
7. El Reverso es rechazado debido a que tampoco encuentra el Pedido de Pago como Pendiente.

En esta simulación no se ha realizado el Pago ni la Devolución.

Situaciones Aceptadas

Son aquellos resultados de los casos de pruebas que no corresponden a lo esperado pero debido a la forma en que está implementado IC se dan como Aceptadas. No son satisfactorias y esas condiciones deben ser revisadas y tener muy presentes para lo que hubiere lugar.

Caracteres Especiales y Código de Autorización

De: Victor Alarcon [mailto:victor.alarcon@bancard.com.py]
Enviado el: jueves, 15 de abril de 2021 18:20
Para: Cristian Cañete <CCanete@cabal.com.py>; Edgar Rojas <ERojas@cabal.com.py>; Jose Cantero <jose.cantero@bancard.com.py>
CC: Juan Zarate <JZarate@cabal.com.py>; Akihiko Kataoka <akihiko.kataoka@bancard.com.py>; Hugo Diaz <hdiaz@cabal.com.py>
Asunto: RE: Resumen de reunion del 11-03-2021

Buenas tardes, la transacción del servicio 133 se debe aprobar, si pueden probar de vuelta.

Respecto a tu consulta @Edgar Rojas

1. Campo 43 Descripción del Comercio:
1. He configurado para sobre escribir lo que venga en las peticiones desde Infonet Cobranzas un texto fijo de 40 caracteres. El texto es >API - Cobranzas                         <
   ¿Esto no representará problema alguno en el proceso de las transacciones? (Peticiones y Reversos)

Entonces lo que haces Edgar es reemplazar lo que recibis por un texto tuyo estático, es correcto?

                             Sí, es correcto.

1. Existen otros campos, además del 43, donde puedan venir los caracteres especiales?

Solo la 43 va a ir con caracteres especiales, ya que es el campo que envia lo que tenemos registrado.

Código de Autorización Infonet Cobranzas:   Te referis a este campo? CODRTN? Me refiero al campo 38.

1. Tengo entendido que para las respuestas aprobadas de peticiones es obligatorio pasar un código de autorización diferente a cero.
   ¿Es correcto?

1. Es necesario retornar un código de autorización para todos los Reversos?