Propuesta para la siguiente release v2

[rogervila]

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]

Toda ayuda de mejora es bienvenida.

[rogervila]

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]

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]

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

[ssheduardo]

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
#95

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

[alphp]

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

[ssheduardo]

@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]

@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]

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

[alphp]

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

[alphp]

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

[alphp]

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

[ssheduardo]

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]

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]

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]

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]

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]

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]

luego lo probaré entonces.

[alphp]

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]

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

[alphp]

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]

@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.