Almacenar datos de pago (tokenización)
Este proceso también conocido como tokenización, consiste simplemente en almacenar los datos de tarjeta de su cliente en nuestros sistemas de forma segura.
Quiere decir que como Comercio podrá tener la tarjeta de todos sus clientes para facilitar sus próximas compras mediante one-click o suscripciones a servicios.
El proceso le creará un identificador de token. Detrás de ese identificador, nuestra plataforma tendrá almacenada los datos completos de la tarjeta menos el CVV.
Este modelo se conoce como tokenización local que quiere decir que ese identificador de token solo se puede utilizar en nuestra plataforma.
Soportamos dos modelos de tokenización local:
- Tradicional
- Wallet de Tokens
| Tradicional | Wallet de Tokens | |
|---|---|---|
| Quién guarda el identificador del token | El Comercio, en su base de datos | Sipay, asociado al identificador de usuario (user_id) |
| Varias tarjetas por usuario | Requiere modelar y mantener la relación en su sistema | Disponible sin cambios en su modelo de datos |
| Qué debe aportar el Comercio | Almacenar el token por usuario | Un identificador de usuario estable y opaco |
| Sincronización con Sipay | Responsabilidad del Comercio | No necesaria |
| Cuándo encaja | Control total del dato y su ciclo de vida | Menor esfuerzo de integración y mantenimiento |
Tradicional
En este modelo el comercio deberá gestionar el identificador de token y almacenarlo en su propia base datos junto con el resto de datos de su usuario.
Para realizar la captura de tarjeta podrá utilizar cualquiera de nuestros métodos de integración:
Wallet de Tokens
En el modelo Wallet de Tokens, Sipay gestiona las tarjetas guardadas de sus usuarios por usted. El Comercio no almacena tarjetas ni identificadores de token: solo necesita un identificador opaco de usuario que ya utiliza en su sistema. Sipay asocia a ese identificador todas las tarjetas que el usuario guarde.
Ese identificador se envía en el campo user_id al generar el enlace de cobro. El valor "0" está reservado y significa no almacenar ni recuperar tarjetas.
Qué obtiene el Comercio
- Sin estado de tarjetas en su sistema. No guarda identificadores de token ni mantiene su ciclo de vida.
- Varias tarjetas por usuario sin cambiar su modelo de datos. No necesita nuevas tablas, relaciones ni migraciones.
- Menos código que mantener. No hay que sincronizar su base de datos con la de Sipay cuando un usuario añade, cambia o elimina una tarjeta.
- Interfaz de gestión de tarjetas ya disponible (ver imagen al final de esta sección).
Qué necesita aportar el Comercio
Un identificador de usuario que sea estable, único y opaco (ver Requisitos del identificador de usuario).
En el diagrama número 2 se puede apreciar cuál debería ser la implementación de un Comercio que quiera tener múltiples tokens por usuario con el modelo tradicional:
En el diagrama 3 se muestra la solución que proporciona nuestra plataforma, sin cambios en su base de datos:
El aspecto visual que obtendrá en nuestro producto será similar a la siguiente imagen.
Requisitos del identificador de usuario
El identificador que envíe a Sipay debe cumplir todos estos requisitos:
- Opaco: no debe contener ni derivarse directamente de datos personales (nombre, email, teléfono, DNI/NIF, fecha de nacimiento), ni siquiera con un hash.
- Estable: no debe cambiar mientras exista la cuenta del usuario.
- Único por usuario dentro de su comercio.
- No predecible: se recomienda un UUID v4 o un valor aleatorio generado por su sistema, no un número autoincremental.
Un hash sin secreto de un dato de bajo espacio (DNI, teléfono, email) puede revertirse por fuerza bruta. No lo use como identificador.
Alternativa si no puede generar un identificador nuevo
Si necesita derivar el identificador de un dato que ya tiene y no puede generar uno nuevo, utilice HMAC-SHA256 con una clave secreta propia del Comercio, almacenada de forma segura. Tenga en cuenta que si pierde o rota esa clave perderá la correspondencia con las tarjetas guardadas.
En el Wallet de Tokens el identificador de usuario da acceso a las tarjetas guardadas de ese usuario. Por ello:
- Úselo solo desde su servidor. Nunca lo exponga ni lo acepte desde el navegador o la aplicación móvil del usuario sin validarlo.
- Obtenga el identificador de la sesión autenticada del usuario en su sistema. No lo reciba como parámetro editable por el cliente: la API exige que
user_idno sea modificable por el cliente. - Si el identificador es predecible (por ejemplo, un autoincremental), un tercero podría intentar acceder a las tarjetas de otros usuarios.