Seguridad y pagos recurrentes
La seguridad en Get Central se basa en cifrado respaldado por hardware y en un token recurrente emitido contra la tarjeta. Esta arquitectura garantiza que los datos sensibles de la tarjeta estén protegidos desde el momento en que son capturados por el PIN pad hasta que son procesados por la red de autorización.
El modelo de seguridad
Todas las operaciones con tarjeta presente dependen de un PIN pad certificado que actúa como el punto de entrada seguro para los datos sensibles de la tarjeta. El dispositivo cifra la información de la tarjeta internamente antes de su transmisión, de modo que los datos en bruto de la tarjeta nunca quedan expuestos a la aplicación POS o al sistema operativo.
El TPVPC Get Central establece un canal de comunicación seguro con el host de autorización utilizando mecanismos SSL/TLS estándar del sector. El TPVPC gestiona íntegramente este canal, incluidas la validación de certificados y la gestión de sesiones, por lo que la aplicación POS no interactúa con material criptográfico ni payloads sensibles.
Como resultado, la aplicación POS nunca procesa ni almacena números de cuenta principales (PAN).
Pagos recurrentes mediante token
Para los casos de uso que requieren card-on-file (tarjeta almacenada) o facturación recurrente, Get Central soporta un token recurrente. Permite ejecutar pagos futuros sin requerir la tarjeta física ni exponer datos sensibles.
El token recurrente está disponible solo cuando se habilita explícitamente y está sujeto a la configuración del terminal y del comercio por parte de la entidad adquirente.
Ciclo de vida del token recurrente
El proceso consta de cuatro pasos:
1. Activación
Antes de registrar tarjetas para uso recurrente, tu aplicación debe activar el modo recurrente llamando a:
fnDllActivaRecurrente()Esta activación dura la sesión de funcionamiento y debe realizarse de nuevo después de cada inicialización de la biblioteca.
2. Primer pago recurrente
El titular de la tarjeta debe estar presente para el registro inicial. La aplicación ejecuta una operación de pago utilizando:
cTipoOper = "PAGO"- un importe válido (incluyendo la validación de valor cero si está habilitada)
Si la operación es autorizada y el token recurrente está habilitado, el host de autorización devuelve el token en la respuesta XML.
3. Recuperación del token
El token generado se devuelve dentro de la respuesta XML, y la aplicación debe almacenarlo para su uso futuro.
| Etiqueta XML | Descripción |
|---|---|
<token> | Token de referencia asociado a la tarjeta. |
El token es una cadena de referencia hexadecimal sin valor intrínseco fuera del ecosistema Get Central.
4. Pagos mediante token recurrente
Para pagos futuros, la aplicación ejecuta una operación de pago utilizando el token almacenado. Estas operaciones no requieren la presencia del titular de la tarjeta ni interacción con el PIN pad.
Las transacciones referenciadas siguen las mismas reglas de autorización que los pagos con tarjeta presente.
Beneficios del token recurrente
El uso de un token recurrente proporciona varias ventajas:
- Datos de tarjeta fuera del POS: Los datos sensibles de la tarjeta nunca entran en la aplicación POS.
- Postura de seguridad mejorada: Los tokens no pueden revertirse para obtener los datos de la tarjeta.
- Flexibilidad operativa: Permite suscripciones, cargos diferidos y modelos de facturación recurrente.
- Comodidad para el cliente: Elimina las interacciones repetidas con tarjeta presente.
Consulta también
- Para obtener detalles sobre la implementación de modelos de suscripción con token recurrente, consulta la guía Gestionar Pagos Recurrentes.
- Para saber más sobre la cadena de comunicación segura entre el POS, el TPVPC y el host, consulta la documentación de Arquitectura.
- Para obtener una lista de los códigos de respuesta relacionados con la seguridad y los errores del host, consulta la referencia de Códigos de Resultado y Errores.