Closed markitosgv closed 10 years ago
Gracias por las correcciones y cambios en el código. Una cosa voy a modificar el método comprobar en la parte de firma y $Ds_Response. Según la documentación: Una vez que el comercio recibe el formulario, el código de respuesta (ds_response) tendrá los siguientes valores posibles:
CÓDIGO SIGNIFICADO
0000 a 0099 Transacción autorizada para pagos y preautorizaciones 0900 Transacción autorizada para devoluciones y confirmaciones 101 Tarjeta caducada 102 Tarjeta en excepción transitoria o bajo sospecha de fraude 116 Disponible insuficiente 118 Tarjeta no registrada 180 Tarjeta ajena al servicio 184 Error en la autenticación del titular 190 Denegación sin especificar Motivo 191 Fecha de caducidad errónea 202 Tarjeta en excepción transitoria o bajo sospecha de fraude con retirada de tarjeta 912/9912 Emisor no disponible
Nota: solo en el caso de las preautenticaciones (preautorizaciones separadas), se devuelve un 0 si está autorizada y el titular se autentica y, un 1 si está autorizada y el titular no se autentica.
Entonces en la parte de comprobar el Ds_Response debe ser menor a 100 y no exactamente 0.
Saludos
2014-03-30 23:28 GMT+02:00 Marcos Gómez Vilches notifications@github.com:
- Añadido método para comprobar si un pago ha sido realizado correctamente
- Cambios en la documentación
- Cambios en la clase sermepa para seguir el estándar PSR1
You can merge this Pull Request by running
git pull https://github.com/markitosgv/sermepa master
Or view, comment on, or merge it at:
https://github.com/ssheduardo/sermepa/pull/13 Commit Summary
- Añadido método para comprobar pago
File Changes
- M README.mdhttps://github.com/ssheduardo/sermepa/pull/13/files#diff-0(17)
- M sermepa.phphttps://github.com/ssheduardo/sermepa/pull/13/files#diff-1(477)
Patch Links:
- https://github.com/ssheduardo/sermepa/pull/13.patch
- https://github.com/ssheduardo/sermepa/pull/13.diff
— Reply to this email directly or view it on GitHubhttps://github.com/ssheduardo/sermepa/pull/13 .
Perfecto Eduardo, tienes razón, de hecho si no vale <100 en el else se podría devolver el código de estado para conocer el error.
El problema de devolver el código de error es que debería ser en negativo según explicamos en el método es comprobar TRUE/FALSE Valores posibles 1 (TRUE), -101, -102, -116, etc (FALSE)
Eduardo D. | Web Developer
http://es.linkedin.com/in/eduardodx/ https://twitter.com/eduardo_dxhttps://github.com/ssheduardo/
El 31 de marzo de 2014, 10:20, Marcos Gómez Vilches < notifications@github.com> escribió:
Perfecto Eduardo, tienes razón, de hecho si no vale <100 en el else se podría devolver el código de estado para conocer el error.
— Reply to this email directly or view it on GitHubhttps://github.com/ssheduardo/sermepa/pull/13#issuecomment-39063912 .
Mmm tienes razón, entonces podría lanzarse una excepción especial que se crease tal que ErrorTransactionException y en el mensaje el código de error, podría ser una solución... O también cambiar true/false en la devolución por un int
Si es así debemos separar la parte de comprobación de firma, para que el usuario vea si el error fue de firma. Hay que darle más vueltas a este método, la cosa es no complicarlo y hacerlo fácil.
Eduardo D. | Web Developer
http://es.linkedin.com/in/eduardodx/ https://twitter.com/eduardo_dxhttps://github.com/ssheduardo/
El 31 de marzo de 2014, 10:31, Marcos Gómez Vilches < notifications@github.com> escribió:
Mmm tienes razón, entonces podría lanzarse una excepción especial que se crease tal que ErrorTransactionException y en el mensaje el código de error, podría ser una solución... O también cambiar true/false en la devolución por un int
— Reply to this email directly or view it on GitHubhttps://github.com/ssheduardo/sermepa/pull/13#issuecomment-39064651 .
Para seguir la simplicidad del código lanzaría una Exception como en el resto del código reportando el error si es el caso de la firma o el error devuelto.
Ok, me parece perfecto.