PUNTOS A TENER EN CUENTA PARA LA CERTIFICACION PSE ANTE ACH DEL SITIO WEB

1. Manejar formato de miles para todos los montos que se muestren en el sitio web del comercio durante todo el proceso de pago.

2. La pagina de respuesta debe mostrar los siguientes datos: nombre y nit de la empresa

(estos datos deben coincidir con la información con la que se creó el código de servicio en ACH para el comercio en cuestión), fecha en que se realiza la transacción, estado de la transacción, referencia del pedido, referencia de la transacción, CUS, banco, valor, moneda, valor en pesos colombianos y descripción. Además debe incluirse el teléfono del comercio para que el cliente pueda comunicarse para hacer consultas sobre sus transacciones.

FIGURA 1. Página de Respuesta

3. La página del banco no debe cargarse dentro de la pagina web de cada comercio, como

se muestra en la figura 2, debe cargarse en la página completa, como se muestra en la figura 3, además se debe evitar el uso de ventanas emergentes.

FIGURA 2. Página del Banco dentro de la página del comercio.

FIGURA 3. Página del Banco cargada correctamente

4. En caso del uso obligado de ventanas emergentes, se debe tener en cuenta que no debe ser posible hacer cambios en los datos de la transacción ingresando a la ventana que se abrió inicialmente.

5. La descripción debe ser clara y referente al producto que se está pagando. No debe

superar los 80 caracteres. Ejemplo: Pago Anualidad Pagosonline.net. 6. Si en el sitio web se maneja una razón social diferente de la registrada en ACH, se debe

enviar el soporte que explique la relación.

NOTA: Si se desea recibir de pagosonline junto con los datos de la transacción PSE, información del comprador, se debe enviar dicha información dentro del objeto para iniciar la transacción PSE, de otra forma pagosonline no tiene como saber datos del tarjeta-habiente, ya que todo el proceso de registro y pago se hace dentro del portal del banco seleccionado.

COMO CUMPLIR LOS PUNTOS DEL CHECK LIST DE ACH PARA LA CERTIFICACION

PUNTO 1. Para cumplir este punto se debe incluir el logo de PSE cuando se muestra este medio de pago al comprador final. PUNTO 2. En este punto se especifica cada cuanto PagosOnline y sus clientes leen la lista de Bancos de PSE. Esta lista debe leerse por lo menos una vez al día. PUNTO 3. Se debe mostrar un desplegable que le permita escoger al comprador el tipo de persona (Natural o Jurídica) antes de realizar el pago. PUNTO 4. Se debe mostrar la lista de bancos en orden alfabético tal como la devuelve el objeto BancoPseWS. PUNTO 5. Se debe abrir la página del banco en una ventana independiente o nueva, tal como se explica en el numeral 3 descrito anteriormente. PUNTO 6. No aplica ninguna recomendación ya que este punto se cumple con la configuración correcta de los convenios en pagosonline. PUNTO 7. MANEJO DE EXCECIONES.

Además de esto se debe tener en cuenta la captura de excepciones a nivel de código, dichas excepciones normalmente traen un código de error implícito y un mensaje, es decisión del comercio si usar el mensaje que trae la excepción o simplemente con base en el código de error, darle al comprador una respuesta personalizada. Ejemplo de captura de excepciones para el método inicarTransaccionPse() en java

1. Si es FAIL_EXCEEDEDLIMIT. Cuando llegue este mensaje, con el código de error -116, se debe mostrar el siguiente mensaje: “El monto de la transacción excede los límites establecidos, por favor comuníquese con la empresa”. En donde la palabra empresa se puede reemplazar con “nuestras líneas de atención al cliente XXX o envíenos sus sugerencias al correo electrónico email@email.com”. Para simular este error se debe generar una transacción por un monto superior a 600000000000.

2. Si es FAIL_BANKUNREACHEABLE. Cuando llegue este mensaje, con el código

de error -115, se debe mostrar el siguiente mensaje: “La entidad financiera no puede ser contactada para iniciar la transacción, por favor seleccione otra o intente más tarde”. Para simular este error se debe escoger el banco mis ahorritos de la lista de bancos del servidor de pruebas.

3. Si es FAIL_ENTITYNOTEXISTSORDISABLED,

FAIL_BANKNOTEXISTSORDISABLED, FAIL_SERVICENOTEXISTS , FAIL_INVALIDAMOUNT, FAIL_INVALIDSOLICITDATE, FAIL_NOTCONFIRMEDBYBANK, FAIL_CANNOTGETCURRENTCYCLE , FAIL_ACCESSDENIED, FAIL_TIMEOUT, FAIL_DESCRIPTIONNO TFOUND o cualquier otro FAIL_xxx, se debe mostrar el mensaje: “No se pudo crear la transacción, por favor intente más tarde o comuníquese con la empresa”.

4. OTRAS EXCEPCIONES COMUNES:

Código error -78: Se intenta pagar una transacción con la misma referencia que aun no ha sido resuelta por PSE. Código error -7: Se intenta pagar una transacción con la misma referencia que ya se encuentra aprobada en el sistema. Código error -104: No se pudo crear la transacción por favor intente más tarde.

5. MECANISMO DE CONSULTA. Se debe incluir en la página de respuesta un

mecanismo para consultar las transacciones realizadas o un número telefónico donde los compradores puedan comunicarse y consultar sus transacciones.

PUNTO 8. Este punto se cumple si se recibe una respuesta del estado final de la transacción correctamente. PUNTO 9. Se debe utilizar el manual de pruebas para generar transacciones y simular los diferentes estados de las transacciones:

1. ESTADO 4 APROBADO para PagosOnline (Para PSE -> APROBADA ): Código respuesta 1: Transacción aprobada.

2. ESTADO 6 RECHAZADO para PagosOnline (Para PSE -> RECHAZADA ): Código respuesta 4: Transacción rechazada por la entidad.

try{ tp = ws.inicarTransaccionPse(tp);

response.sendRedirect(tp.getUrlPaginaPagosBanco()); }catch(AxisFault e){ logger.error("Codigo Error :" + e.getFaultCode().getLocalPart()); logger.error("Causa Error :" + e.getFaultReason()); }

3. ESTADO 6 RECHAZADO para PagosOnline (Para PSE -> FALLIDA ): Código respuesta 5: Transacción declinada por la entidad

4. ESTADO 12 PENDIENTE POR CONFIRMAR PSE para PagosOnline (Para PSE -> PENDIENTE ):

Código de respuesta 9994: Transacción pendiente por confirmar.

• NOTA: Recuerde que para PSE cualquier transacción que aun no ha sido resuelta, es decir, no se tiene certeza en qué estado está o que código de respuesta ha generado, se debe marcar como PENDIENTE .

PUNTO 10. Si se obtienen alguno de los siguientes mensajes, FAIL_INVALIDTRAZABILITYCODE, FAIL_ACCESSDENIED, FAI L_TIMEOUT, la transacción debe manejarse como una transacción PENDIENTE. PUNTO 11. Se debe garantizar que si se modifica la URL de respuesta, se generará un error. PUNTO 12 y 13. No aplica ninguna observación. La plataforma de pagos cumple con este requisito. PUNTO 14. Para validar el doble pago, se debe usar el email del comprador.

1. Caso 1. Si se tienen transacciones con estado PENDIENTE para un mismo email, se debe mostrar un mensaje informando sobre las transacciones pendientes, figura 4, y el detalle de estas transacciones debe tener los mismos datos que se muestran en la página de respuesta, figura 5.

FIGURA 4. Mensaje transacciones pendientes

FIGURA 5. Detalle transacciones pendientes.

2. Caso 2: Se debe garantizar que cada transacción tenga un ID diferente, que no se

permita pagar una transacción, con una referencia especifica o un numero de factura, dos veces.

PUNTOS 15 – 19. No aplica ninguna observación.