Seguridad y datos de tarjetas
Cobrar pagos dentro de Salesforce plantea las preguntas que hace todo administrador y auditor: adónde van los números de tarjeta, qué se guarda, quién puede ver qué y qué tenemos que hacer nosotros. Este artículo las responde para REDA Pay 1.56 tal como está construido, y enumera las responsabilidades que siguen siendo tuyas.
Lo que nunca se guarda en Salesforce
| Dato | Tratamiento |
|---|---|
| Número completo de la tarjeta (PAN) | Nunca se escribe en ningún registro de Salesforce. Después del registro, solo se conservan la marca, el tipo, el mes y año de vencimiento, el nombre del titular y el código postal de la tarjeta, y el nombre del método muestra los últimos cuatro dígitos |
| Código de seguridad de la tarjeta (CVV/CVC) | Nunca se guarda |
| Número completo de la cuenta bancaria | Nunca se guarda. Se conservan el número de ruta, el tipo de cuenta, la clase, la moneda, el nombre del titular y los últimos dígitos (en el nombre) |
Lo que se guarda cifrado
REDA Pay cifra lo siguiente con una clave que se genera una sola vez en tu organización y nunca se muestra; consulta Generar la clave de cifrado:
- el token de API de Payload en el Pay Profile;
- los identificadores de Payload de tu organización (Profile Id), de cada cuenta de comerciante, de cada cliente y de cada método de pago guardado (el token que usa Payload en lugar de la tarjeta o la cuenta);
- el identificador dentro de cada enlace de pago.
Quien pueda leer estos registros ve texto cifrado. El identificador de transacción de Payload se guarda sin cifrar, porque es un número de referencia que se usa en las conversaciones con soporte y no contiene ningún secreto.
Cómo viajan los datos de tarjetas y cuentas bancarias
En las pantallas de pago y para guardar métodos, el pagador escribe los datos de la tarjeta o la cuenta bancaria en el formulario de REDA Pay. REDA Pay los envía a Payload por una conexión cifrada, Payload devuelve un token y REDA Pay conserva el token y los datos descriptivos antes mencionados. Los datos pasan por tu organización de Salesforce de camino a Payload; no se escriben en un registro, un log ni un archivo.
Qué significa esto para ti:
- Trata tu organización de Salesforce como parte del entorno que maneja datos de tarjetas y mantenla segura: autenticación robusta para todos los usuarios, acceso con el mínimo privilegio, sin registros de depuración de las pantallas de pago en producción.
- Habla con Payload y con tu evaluador sobre lo que esta arquitectura significa para el alcance de tu PCI DSS y el cuestionario que completas. El diseño de REDA Pay mantiene los datos de tarjetas fuera de tu base de datos; por sí solo no te deja "fuera del alcance".
- También se puede mantener a los pagadores totalmente alejados de tu personal con los enlaces de pago y el portal, para que el personal nunca vea ni escriba números de tarjeta.
Sesiones, enlaces e invitados
| Mecanismo | Qué protege |
|---|---|
| Sesión de pago cifrada | Cada pantalla de pago funciona a partir de un token cifrado que se crea al abrirse y lleva quién paga, con qué perfil y qué cuenta. Vence según la duración de sesión de la cuenta (15 minutos de forma predeterminada), así que una dirección copiada o guardada en favoritos no se puede reutilizar más tarde |
| Identificador de enlace cifrado | Un enlace de pago lleva cifrado el identificador de la orden; la dirección no revela nada sobre el importe ni el cliente |
| Acceso de invitados por regla | El usuario invitado del sitio público puede leer una Pay Order solo mientras Has Active Link sea verdadero, y un Pay Customer solo mientras tenga un enlace activo, mediante las reglas de colaboración que creas. Cuando un enlace se paga, vence o se revoca, los registros salen de la vista del invitado |
| Métodos de invitado de un solo uso | Una tarjeta o cuenta ingresada en un enlace se guarda con Keep Active desactivado |
| Protección contra duplicados | Se rechaza una segunda pulsación del botón de pago en la misma sesión |
| Captura de geolocalización e IP | Registro opcional, y obligatoriedad, de desde dónde se hizo un pago; consulta Controles |
Actualizaciones de estado desde Payload
Payload informa los eventos a una dirección pública de tu organización. El mensaje solo se usa para saber qué transacción cambió; luego REDA Pay lee la transacción en Payload mediante la API autenticada y guarda eso. Nada de un mensaje entrante se escribe directamente en un registro. Consulta Configurar webhooks.
Quién puede hacer qué
El acceso lo conceden siete conjuntos de permisos, desde solo lectura hasta administrador, y dos interruptores en el registro de usuario para cobros y desembolsos; consulta Quién puede hacer qué. La mayoría de los objetos de REDA Pay son de lectura pública dentro de la organización, así que cualquier usuario con licencia y acceso al objeto puede leer los registros de pago; restríngelo con tu propia configuración de colaboración si tu política lo exige. El seguimiento del historial de campos está activado en la mayoría de los campos, lo que te da un registro de auditoría de los cambios.
Tu lista de comprobación antes de la puesta en marcha
| Elemento | Por qué |
|---|---|
| ERROR_STACK_TRACE definido en FALSE | El detalle técnico no debe llegar a los pagadores; consulta Interruptores de la organización |
| Conjuntos de permisos asignados por función, Enable Disbursements solo donde haga falta | Mínimo privilegio |
| Conjunto de colaboración del portal y reglas de colaboración de invitados exactamente como se documentan | Los clientes solo ven sus propios registros; los invitados, solo los enlaces activos |
Logotipo y pie de página servidos por https | Sin contenido mixto en la página de pago |
| Autenticación multifactor para el personal que cobra pagos | Buena práctica de Salesforce |
| Registros de depuración desactivados para los usuarios de pagos en producción | Los registros pueden capturar datos de las solicitudes |
| Un responsable designado para la vista Attention Needed de REDA Pay Logs | Que alguien vea los fallos |
| Claves de API de Payload guardadas solo con Update API Token, nunca en campos, documentos ni chats | La clave es la cuenta |
| Tarjetas de prueba y el entorno de prueba de Payload en los sandboxes | Nunca tarjetas reales en pruebas |
Preguntas frecuentes
REDA Pay es una aplicación que funciona en tu organización de Salesforce; el procesador de pagos es Payload. Pide a Payload su certificación y pregunta a tu evaluador cómo afecta a tu propio alcance una integración que hace pasar datos de tarjetas por tu organización. Este artículo te dice exactamente qué hace la aplicación para que esa conversación esté bien fundamentada.
Sí: el propietario y el creador de la Pay Order, Processed User Type y, cuando se capturan, IP Address, Geo Latitude y Geo Longitude.
No se puede exportar ni volver a generar, y está en tu organización. Los sandboxes tienen la suya; la de producción se queda en producción.