Seguridad de pago en su tienda online: PCI, card testing y qué hace su proveedor de hosting
Quien recibe pagos en línea tiene que enfrentarse a las normas de seguridad de las compañías de tarjetas (PCI DSS), a delincuentes que quieren robar datos de tarjetas y al card testing: probar tarjetas robadas en su tienda. Este artículo explica qué significa esto para una tienda online pequeña, qué debe hacer usted mismo y qué le soluciona su proveedor de hosting y qué no.
La regla principal: los datos de tarjetas nunca llegan a su tienda
El número de tarjeta, la fecha de caducidad y el código de seguridad los introduce el cliente en su proveedor de pagos, no en su propia tienda. Su tienda solo recibe la información de si se ha pagado o no. Esto también significa:
- no utilizar nunca un campo de formulario propio para números de tarjeta, tampoco para un pedido telefónico;
- no aceptar nunca datos de tarjetas por correo, chat o teléfono ni anotarlos en una nota junto a un pedido;
- no utilizar ningún plugin que guarde datos de tarjetas en su propia base de datos.
PCI DSS y SAQ A en lenguaje sencillo
PCI DSS (Payment Card Industry Data Security Standard) es el estándar de seguridad de las compañías de tarjetas; la versión actual es v4.0.1. Una empresa que procesa los datos de tarjetas por sí misma recibe con ello un amplio conjunto de requisitos. Una tienda pequeña que subcontrata por completo el pago demuestra que cumple mediante un breve cuestionario: el SAQ A (Self-Assessment Questionnaire A). Su proveedor de pagos se lo puede solicitar.
La subcontratación se puede hacer de dos formas:
- Redirección: tras realizar el pedido, el cliente va a la página de pago del proveedor y después vuelve.
- Un campo de pago integrado: el campo de pago está en su página de pago, pero es un fragmento de página (iframe) del proveedor.
Desde el 31 de marzo de 2025 rige una nueva versión del SAQ A. Quien utilice un campo de pago integrado debe confirmar en él que su sitio no es vulnerable a ataques con scripts que puedan afectar al pago. Quien utilice redirección no está sujeto a esa condición. Pregunte a su proveedor de pagos qué cuestionario corresponde a su integración.
Proteger la página de pago
- Mantenga la página de pago despejada. Cualquier script en esa página puede, en principio, leer lo que el cliente introduce (e-skimming): widgets de chat, gestores de etiquetas, píxeles publicitarios. Cargue allí únicamente lo necesario para el pago.
- Pocos plugins, y siempre actualizados. Los scripts maliciosos suelen entrar a través de una vulnerabilidad en un plugin o de una contraseña de administrador robada.
- https en todas partes, con redirección de http a https y HSTS. Consulte Redirigir obligatoriamente a los visitantes a https y HSTS y cabeceras de seguridad para su sitio web.
Reconocer y limitar el card testing
En el card testing, los delincuentes realizan automáticamente muchos pedidos pequeños para comprobar qué tarjetas robadas funcionan. Se reconoce por muchos pedidos en poco tiempo, a menudo del mismo producto barato, con nombres variables y muchos pedidos con el estado Fallido. Esto le supone costes de transacción y devoluciones de cargo, y en el peor de los casos su proveedor de pagos bloquea su cuenta.
- Rate limiting (un límite al número de solicitudes por tiempo). WooCommerce lo tiene integrado para los bloques de pago, pero está desactivado de forma predeterminada. Actívelo en WooCommerce > Ajustes > Avanzado > Funciones, opción Rate limiting Checkout block and Store API.
- Un captcha al realizar el pago. Los atacantes suelen cambiar de dirección IP; rate limiting y captcha juntos funcionan mejor.
- Los filtros antifraude de su proveedor de pagos. Actívelos y revise lo que notifican.
- 3-D Secure, la confirmación adicional en la aplicación bancaria, dificulta el uso indebido de tarjetas robadas.
Qué hace su proveedor de hosting y qué no
Resuelto por WebOké:
- Un certificado gratuito de Let's Encrypt para https
- HSTS está activado de forma predeterminada en la mayoría de los servidores
- El Web Application Firewall está activado de forma predeterminada y bloquea los ataques conocidos
- Imunify360 comprueba inmediatamente si hay malware en los archivos nuevos y escanea su paquete con regularidad
- Cada noche se hace una copia de seguridad de todo su paquete, conservada durante 30 días, en otro centro de datos
Queda bajo su responsabilidad (o la de su desarrollador web):
- Actualizar WordPress, WooCommerce, el tema y los plugins (Installatron puede hacerlo automáticamente, consulte Actualizaciones y actualizaciones automáticas)
- La integración y los ajustes antifraude en su proveedor de pagos
- Qué scripts hay en su página de pago
- Contraseñas seguras y verificación en dos pasos para los administradores
- Rate limiting, captcha y la revisión de pedidos sospechosos
El software que instala usted mismo, también a través de Installatron, lo gestiona usted. Si su sitio sufre de todos modos un hackeo, siga el plan de pasos Mi sitio web ha sido hackeado: plan de pasos. Si una intrusión afecta a datos personales de clientes, lea también ¿Es esto una filtración de datos y debo notificarlo?
Más información
- Curso gratuito Seguro en línea, lección 4.2 Su sitio web: https, HSTS y cabeceras de seguridad
- PCI Security Standards Council sobre SAQ A (en inglés)
- WooCommerce sobre card testing y rate limiting (en inglés)