Pago Billetera Virtual de Telefonica ( Paraguay) para Woocommerce (Plugin)

Entregables:
* el codigo fuente del nuevo plugín.
* Un manual de usuario en español en formato pdf.
* 1 mes de soporte en caso de cualquier fallo en el plugín.

Crear un plugin (pasarela de pago) para pago con billetera virtual de telefónica.
Overview
La API Botón de Pago  es una plataforma que permite a los desarrolladores (merchants) de aplicaciones Web y móviles integrar el plugin como medio de pago simple, práctico y seguro, para poder registrar pagos de sus usuarios.
La integración se hace por medio de una API RESTful basado en arquitectura OAuth para autenticación. La plataforma está hosteada en la nube de Apigee, con alta disponibilidad, transaccionalidad y escalabilidad.

Las transacciones con el Botón de Pago  se realizan de forma asíncrona: el merchant realiza una solicitud de pago, y debe esperar la respuesta (callback) en un servidor accesible desde Internet.

Conectividad y Comunicación
Toda la comunicación tiene lugar sobre el protocolo HTTPS, desde el servidor del merchant al entorno de servidor en Apigee. (En la nube)

Las URIs para la integración son:
 Test
o Token: https://xxxx/xxxxx/xxxxx/xxxx/xxxx
o Pagos: https://xxxxx/xxxx/xxxx/xxxxx/xxxx
 Producción
o Token: https://xxxx/xxxx/xxxx/xxxx/xxxxx
o Pagos: https://xxxx/xxxx/xxxx/xxxx/xxxxx

Token de sesión
Para cada request (Pago, Reversión, Consulta de estado) se debe solicitar un token de acceso mediante el servicio GenerateAccessToken utilizando el key y secret de la API. El token tiene un periodo de validez limitado, y luego de completado un request el token es invalidado.
El proceso se ilustran en las especificaciones.

Autorización de Pago
El servicio de Autorización de Pago se basa en un URI redirect por medio del cual la autorización y el pago propiamente por parte del usuario de la Telefonia son manejados completamente en los servidores de la telefonica. Las siguientes secciones ilustran el flujo.
Un pago es autorizado por dos factores: posesión del número de teléfono (verificación OTP), y clave de la telefonia.

Verificación OTP
Una vez ingresado un número de cuenta de la telefonia (msisdn) se envía un sms al usuario para validar que está en posesión de la línea telefónica asociada a la billetera.

Autenticación de Clave
La clave o PIN de la telefonica es un código numérico de 4 dígitos que autoriza las transacciones de billetera electrónica

Callback y Redirect URIsLuego de finalizada la transacción, se notifica el resultado por medio de un callback y se redirige
al usuario a un URI definido por el merchant

El suscriptor (cliente de la telefónica) inicia un pago en el sitio web  del comercio Woocommerce (merchant)
El merchant solicita un token al servidor de pagos de la telefonica utilizando sus credenciales (API key y secret).
El merchant solicita el pago utilizando el token y otros datos necesarios (API key secret). Esto devuelve un URI al cual se re-direcciona al usuario.
El servidor de la Telefonica despliega una pantalla para identificar la línea (MSISDN) del suscriptor.
El suscriptor ingresa el sms de verificación recibido (otp)
el servidor de la telefonica despliega una pantalla para autorizar la transacción con la clave del suscriptor
el suscriptor ingresa su clave
la transacción se completa y el merchant recibe el resultado en el url de callback que haya configurado en el request
se re-dirige al usuario de nuevo al sitio de donde vino por medio del uri de redirección configurado en el request

generación de token
cada operación (pago, reversión, consulta) necesita un token de seguridad adquirido previamente con las credenciales (api key y secret) del comercio. Para ello se hace un request http post al url,
ej.  https://secureserver.com/test/oauth/mfs/payments/tokens
El token puede usarse sólo una vez, y tiene una validez de 10 minutos

Autorización de pago
Request
Para iniciar una autorización de pago se debe enviar un post incluyendo un objeto json

callback de status
luego de que el cliente completa el pago, el status se reporta asíncronamente al callback uri (opcional) si es que fue especificado.


En caso de que la transacción no sea exitosa (transactionStatus = fail), el motivo recibido en transactionCode ofrece una causa probable. Hay una lista completa de escenarios de error y respuestas posibles.
Luego del callback se emite una directiva HTTP Redirect para redireccionar al cliente

Redirección del cliente
Independientemente de si hay o no un callbackURI en el request de pago, se reporta el status  finalmente a la dirección específicada en el parámetro obligatorio redirectURI

En caso de que la transacción no sea exitosa (transactionStatus = fail), el motivo recibido en transactionCode ofrece una causa probable. La lista completa de escenarios de error y respuestas posibles se encuentra en el apéndice.

Reversión de Pago
Una transacción exitosa puede ser revertida por el merchant, por ejemplo por cancelarse o modificarse el pedido de un cliente, pero en general realidad el motivo de la reversión queda a criterio del comercio.
Al revertirse, la totalidad del monto pagado se debita de la billetera del merchant y vuelve a la del
cliente. La única restricción es que la reversión debe tener lugar dentro de los 30 días posteriores a
la transacción original.
Para realizar una reversión, es necesario obtener primero un token

Request
La reversión de la transacción se hace con el método http delete:

consulta de transacción
el merchant puede realizar una consulta para verificar el estado de una transacción (success, fail, reverted). Para realizar una consulta de transacción, es necesario obtener primero un token

Request
Para consultar el estado de una transacción se utilizar http get con el mismo url que para la reversión. La única diferencia es el método HTTP.