[CONSEJO — Doc 10] Contrarian: SalesMind procesa transacciones de pago, lo que agrega un nivel de riesgo que StockMind no tiene. No hay que ser PCI DSS Level 1 desde el día 1, pero sí entender qué datos de tarjeta toca el sistema y cuáles delega a la pasarela. First Principles: La regla de oro del POS es: nunca tocar datos de tarjeta directamente. ONVO Pay, Tilopay y cualquier pasarela de pagos se encargan del procesamiento de tarjeta. SalesMind solo recibe la confirmación (aprobado/rechazado) y el token de referencia de la transacción. Nunca el PAN, CVV ni fecha de vencimiento. Executor: El audit trail de transacciones del POS es más crítico que el de StockMind. Un cliente que alega "esta venta no la hice" necesita evidencia: qué cajero la procesó, a qué hora, en qué dispositivo, con qué medio de pago. El audit log del POS debe ser tan detallado como el de un banco.
1. Modelo de amenazas específico del POS
| Amenaza | Riesgo | Control |
|---|---|---|
| Cajero registra venta falsa | Fraude interno | Audit trail por cajero + separación: cajero no puede ver historial total |
| Descuento no autorizado en POS | Pérdida de revenue | Límites de descuento configurables por rol |
| Venta cancelada sin motivo documentado | Fraude o error | Void requiere supervisor_id + razón obligatoria |
| Intercepción de datos de tarjeta | Robo de datos PCI | Nunca tocar datos de tarjeta — delegar 100% a pasarela |
| Inyección en sync offline | Manipulación de datos | Validación estricta de payload offline + checksums |
| Acceso a datos de ventas de otro tenant | Cross-tenant leak | RLS PostgreSQL + tenant_id en JWT (heredado de StockMind) |
2. PCI DSS — Alcance del sistema
SalesMind opera bajo PCI DSS SAQ A (el nivel más simple) porque: - No almacena datos de tarjeta (PAN, CVV, track data) — solo el token de referencia de la transacción - No procesa datos de tarjeta directamente — la pasarela (ONVO Pay / Tilopay) lo hace - No transmite datos de tarjeta en la red de SalesMind
La responsabilidad del cumplimiento PCI para el procesamiento de tarjeta recae en ONVO Pay / Tilopay (ambos tienen certificación PCI DSS).
Lo que SalesMind almacena de cada transacción con tarjeta:
{
"payment_method": "card",
"payment_status": "paid",
"gateway_reference": "onvo_txn_abc123", // referencia de la pasarela, no datos de tarjeta
"last_four": "4242", // últimos 4 dígitos (permitido bajo PCI)
"card_brand": "Visa" // marca de la tarjeta (permitido)
}
3. Controles específicos del POS
3.1 Autenticación del cajero
El cajero se autentica en el POS con su usuario y un PIN de 4 dígitos (adicional al magic link general). El PIN es: - Diferente para cada cajero - Almacenado como bcrypt hash (nunca en claro) - Requerido cada vez que se abre la sesión del POS (no persistente entre shifts) - Configurable para expirar después de N minutos de inactividad
3.2 Límites de descuento por rol
DISCOUNT_LIMITS = {
'cashier': 0.05, # máx 5% de descuento sin aprobación
'manager': 0.20, # máx 20% sin aprobación del dueño
'owner': 1.0, # sin límite
}
Si un cajero intenta aplicar un descuento mayor a su límite, el POS bloquea y requiere código de aprobación del manager (enviado por SMS/email en tiempo real).
3.3 Void (cancelación de venta)
El void de una venta requiere: 1. Autenticación del supervisor (otro usuario con rol ≥ manager) 2. Razón seleccionada de lista predefinida (error de cobro / devolución de producto / falla de sistema / otro) 3. Nota opcional 4. El void queda registrado en el audit log con: venta original, usuario que hizo void, usuario que aprobó, razón, timestamp
El void no elimina la venta original — crea un registro separado de tipo 'void' que se contabiliza como reversal en los reportes.
3.4 Sync offline — validaciones de seguridad
El payload de sync offline es validado estrictamente:
- Checksum SHA-256 del payload completo (generado en el dispositivo, verificado en el servidor)
- Timestamp debe estar dentro de ±24h del servidor (evita replay attacks)
- offline_id debe ser único (evita duplicados)
- Cantidad vendida no puede exceder el stock disponible en el momento del sync (con tolerancia para ventas simultáneas offline)
4. Datos personales (Ley 8968) — SalesMind específico
SalesMind procesa datos personales adicionales que StockMind no procesa: - Datos de clientes CRM: nombre, email, teléfono, historial de compras, sector - Datos de reps comerciales: nombre, email, historial de ventas, comisiones
Base legal del tratamiento: - Datos de clientes: ejecución del contrato de servicio entre SalesMind y el tenant cliente - Datos de reps: ejecución del contrato de servicio + interés legítimo del tenant
Derechos ARCO: - Un cliente final de la ferretería (que aparece en sl_customers) puede ejercer derecho de acceso o cancelación. El tenant (la ferretería) es el Responsable — SalesMind facilita la exportación o eliminación de esos datos bajo instrucción del tenant.
Retención: - Historial de ventas: 7 años (obligación fiscal CR para comprobantes) - Datos de clientes CRM: eliminados o anonimizados 30 días después de que el tenant cancela
5. Audit trail específico del POS
Eventos adicionales auditados en SalesMind (además de los heredados de StockMind):
| Evento | Datos registrados |
|---|---|
| Venta completada | sale_id, cashier_id, customer_id, total, payment_method, device_ip |
| Descuento aplicado | sale_id, sku_id, discount_pct, authorized_by (si requirió aprobación) |
| Void realizado | original_sale_id, void_by, approved_by, reason, timestamp |
| Precio actualizado por motor | sku_id, old_price, new_price, approved_by, motor_suggestion_id |
| Precio rechazado | sku_id, suggested_price, rejected_by, reason |
| Login cajero en terminal | user_id, device_id, terminal_ip |
6. Inherited controls from StockMind
Todos los controles de seguridad de StockMind aplican a SalesMind:
- Magic link + JWT (ver StockMind Doc 10 §2)
- RBAC (ver StockMind Doc 10 §3)
- RLS PostgreSQL (misma política en tablas sl_*)
- TLS 1.3 + HSTS
- Cloudflare WAF + rate limiting
- Sentry error tracking
- structlog con sanitización de datos sensibles
Ver también: Doc 07 (SRD Backend — implementación técnica del sync POS y audit trail) · Doc 08 (Modelo de Datos — estructura de sl_sales y sl_audit_log) · Doc 14 (Marco Legal — ToS y DPA para datos de clientes del CRM) · StockMind Doc 10 (controles base heredados)