Propuesta para la siguiente release v2

rogervila commented 1 year ago

Hola,

Propongo trabajar en la siguiente release (V2), incluyendo los siguientes cambios:

Soporte para PHP >= 8.1.0
Types en todos los métodos y parámetros
Enums en lugar de Strings (ejemplo: Environment, Language, Transaction Type, etc)
Borrar métodos deprecados
Excepciones detalladas

@ssheduardo si te parece bien puedo empezar a trabajar en una PR.

Saludos.

ssheduardo commented 1 year ago

Toda ayuda de mejora es bienvenida.

rogervila commented 1 year ago

Perfecto, empezaré a trabajar en la PR.

Mientras tanto, podrías publicar el tag v1.5.0 con los últimos cambios en master?

Saludos.

ssheduardo commented 1 year ago

El último cambio que se hizo por un PR fue el de [hash_equals()], si eso sería pasar a las versión 1.4.5

rogervila commented 1 year ago

Perfecto. Si lo publicas como v1.4.5 está bien.

ssheduardo commented 1 year ago

Te he dejado comentarios en el PR, por cierto voy a subir una nueva versión para el tema del insite que me han dado feedback https://github.com/ssheduardo/sermepa/issues/95

Lo digo para actualizar lo que se tiene hasta ahora y aprovechar a los que usan la versión 1.x

alphp commented 11 months ago

He creado un PR #96 con una propuesta para las constantes.

ssheduardo commented 11 months ago

@alphp el compañero @rogervila esta trabajando en la v2 para pillar 8.1.0 como mínimo, tal vez tocaría esperar a que acabe para ir agregando más cosas.

alphp commented 11 months ago

@ssheduardo son nuevas clases en archivos independientes porque de esta forma se pueden integrar sin problemas en ambas ramas. De hecho no se modifica para nada el Tpv.php para permitir una mayor independencia hasta que se decida integrarlo.

ssheduardo commented 11 months ago

@alphp cierto, no me había fijado que era el TvpTest donde estabas realizando estos cambios.

alphp commented 11 months ago

@ssheduardo Creo que eliminaré esos cambios del TpvTest y crearé un nuevo test exclusivo para las clases de constantes.

alphp commented 11 months ago

He creado una issue #97 para comentar ahí los temas de las constantes.

alphp commented 10 months ago

Creo que sería buena idea añadir métodos REST para devoluciones y anulaciones de pre-autorizaciones. ¿Quizás como clases separadas?

ssheduardo commented 10 months ago

Si, hay muchas cosas que podemos agregar. El problema para probar esto es que no cuento con acceso a un entorno de Test por parte de Redsys. He llamado para solicitarlo comentando que tengo esta librería, pero ni caso. Quise ver si podía contratar el servicio aunque sea unos meses para testear y probar más cosas pero nada, tenían que estudiar el caso y aprobarlo, encima tenía que ser empresa. La verdad que no lo ponen nada fácil, encima sería guay poder probar el tema de Insite que lo estuve viendo en un proyecto.

alphp commented 10 months ago

Yo tengo acceso a un entorno de pruebas. ¿Cómo te parece que nos organicemos? Podemos crear una rama para añadir y probar una nueva clase REST. De todas formas a mi el REST me interesa más por el tema de devoluciones/anulaciones, el tema del pago seguiré haciéndolo mediante redirección porque me parece más cómodo.

ssheduardo commented 10 months ago

Claro, el tema Rest va venir genial la verdad para las pruebas y todo, en la clase TPV esta la url a Rest si no me equivoco. Y si tienes entorno de pruebas mejor, así hasta me da opción de hacer tutoriales para la comunidad

alphp commented 10 months ago

Me sonaba que en la documentación había datos de un entorno de pruebas genérico, sin acceso al panel de administración pero funcional para simular pagos: https://pagosonline.redsys.es/entornosPruebas.html

Acabo de probarlos y funciona estupendamente:

Datos de prueba genéricos

Se proporcionan unos datos genéricos de prueba para la realización de pruebas. Para obtener los datos específicos de su comercio, deberá contactar con su entidad bancaria.

Ds_Merchant_MerchantCode: Es el número de comercio único facilitado por su entidad bancaria.
- El número de comercio genérico para realización de pruebas en test es 999008881.
Ds_Merchant_Terminal: El número de terminal es el número asignado al terminal facilitado por la entidad bancaria.
- El número de terminal genérico para realización de pruebas en test es 001.
Clave Comercio: Es una clave firma única suministrada por su entidad bancaria.
- La clave de comercio genérica para realización de pruebas en test es sq7HjrUOBfKmC576ILgskD5srU870gJ7.

NOTA: Si se solicita un código de autenticación, introducir 123456.

ssheduardo commented 10 months ago

Para hacer la redirección si funciona esos datos de pruebas pero ya ir a más ya no vale, por ejemplo Insite. Lo que no he probado a hacer devoluciones por Rest usando previamente la redirección.

alphp commented 10 months ago

En principio los mismos datos sirven para REST y redirección. En el entorno de pruebas que tengo del TPV que tengo contratado me permite seleccionar también SOAP. Por lo que he visto para InSite e InApp se requiere otro contrato o que lo active el banco.

ssheduardo commented 10 months ago

luego lo probaré entonces.

alphp commented 10 months ago

Acabo de hacer una prueba de una compra con redirección y la devolución con REST mediante la v1 y el entorno de pruebas genérico: PERFECTO.

ssheduardo commented 10 months ago

si podemos documentarlo, aunque es una chorrada pero al resto le puedo servir.

alphp commented 10 months ago

Este es el código de la devolución, obviamente el número de orden (setOrder) y la cantidad (setAmount) se corresponden con una compra anterior:

    $key = 'sq7HjrUOBfKmC576ILgskD5srU870gJ7'; // Sustituir por la key real para producción

    $redsys = new Tpv();
    $redsys->setAmount(1.010);
    $redsys->setOrder('A1703155014');
    $redsys->setMerchantcode('999008881'); // Sustituir por el Merchantcode real para producción
    $redsys->setCurrency('978');
    $redsys->setTransactiontype('3');
    $redsys->setTerminal('1');
    $redsys->setEnvironment('restTest'); //Entorno test, sustituir por restLive para producción

    $signature = $redsys->generateMerchantSignature($key);
    $redsys->setMerchantSignature($signature);

    try {
        $response = $redsys->send();
        $response = json_decode($response, true);
        $parameters = $redsys->getMerchantParameters($response['Ds_MerchantParameters']);
        $DsResponse = $parameters['Ds_Response'] ?? 99999999999;
        $DsResponse += 0;
        if ($redsys->check($key, $response) and ($DsResponse <= 99 or $DsResponse == 900 or $DsResponse == 400)) {
            //Si es todo correcto ya podemos hacer lo que necesitamos, para este ejemplo solo mostramos los datos.
            print_r($parameters);
        } else {
            //acciones a realizar si ha sido erroneo
        }
    } catch (Exception $e) {
        echo $e;
    }

Es importante tener en cuenta que al ser una devolución el código de respuesta que nos indica que la operación ha sido correcta es distinto:	Código	Significado
0000 a 0099	Transacción autorizada para pagos y preautorizaciones
0900	Transacción autorizada para devoluciones y confirmaciones
0400	Transacción autorizada para anulaciones

Actualizado 2024-01-04: Notas aclaratorias para indicar que el entorno de producción debe ser "restLive".

rogervila commented 10 months ago

@alphp muchas gracias por el ejemplo de devolución.

En la V2 se usaran Enums para todo así que el código quedará más claro.

ssheduardo / sermepa

Propuesta para la siguiente release v2 #93

Datos de prueba genéricos