¿Cuáles son los pasos a seguir para transmitir de manera segura la información de la tarjeta de crédito a través de un formulario web estándar?

No puedo enfatizar lo suficiente que esto es altamente "involucrado".

1. Debería ser compatible con PCI DSS, ya que manejará los datos de la tarjeta. PCI DSS es la definición de involucrados. Tampoco estoy seguro de dónde se encuentra con alguien que realmente copie esta información en un punto de venta, pero me imagino que sería extremadamente difícil generar un proceso de quejas que incluya este paso.

2. Los datos deberán estar protegidos durante el tránsito, por lo que eso significa configurar un servidor SSL / TLS para que solo admita cifrados, protocolos y otros ajustes de configuración fuertes y no vulnerables. Deberá comprar un certificado SSL / TLS y mantenerlo actualizado. Además, deberá considerar cualquier cifrado de transporte más allá del servidor web ... por ejemplo, definitivamente no puede enviar estos datos por correo electrónico a su copiador.

3. Los datos deberán estar protegidos en reposo (y deberán estar en reposo en algún momento si no se transfieren inmediatamente a un procesador de pagos independiente). Esto significa que todos los detalles de la tarjeta deberán cifrarse utilizando un esquema sólido, que probablemente incluya formas tanto simétricas como asimétricas. Las claves deberán administrarse de forma segura para evitar que se acceda a los datos.

4. Es necesario establecer un Entorno de Datos de Tarjeta (CDE) seguro, una red altamente segura que esté separada de otras áreas comerciales. El acceso a este debería ser controlado estrictamente.

5. Tanto la aplicación web (formulario) como la infraestructura de red deben probarse / revisarse periódicamente para detectar vulnerabilidades de seguridad, que luego deben administrarse y resolverse.

Esto realmente solo raspa la superficie. Pruebe los requisitos de PCI DSS para obtener una comprensión completa de los pasos involucrados en el manejo seguro de los datos de la tarjeta.

Sería mucho más fácil y barato, especialmente para una pequeña operación, utilizar un servicio de terceros que ya haya pasado por estos procesos. Para una facilidad de uso extrema, un servicio listo para usar como PayPal podría ser utilizado. Si está interesado en usar su propio formulario, considere un servicio como Stripe que puede manejar el back-end y la seguridad. Estos servicios ya son compatibles con PCI.

Bien ... supongamos por un segundo que uno debe seguir adelante con el plan donde:

• El cliente del cliente ingresa la información de CC (CC #, ExpDate, Address, Name, CVV #) en su sitio
• Su cliente luego recupera estos datos y los ingresa manualmente en un terminal POS

Además de ser horriblemente ineficiente, aquí están los BSD (Big Scary Details):

• Su servidor ahora está manejando Y almacenando los datos de la tarjeta de crédito. Esto significa que ahora está "dentro del alcance" en cuanto a estándares de PCI . Por cierto, los datos CVV NUNCA se pueden almacenar en ningún momento ... en cualquier lugar
• Estos datos se deben cifrar tanto en tránsito como en reposo en el servidor
• Su servidor debe someterse a exploraciones de vulnerabilidad periódicas por un servicio aprobado por PCI
• Su empresa debe tener implementados controles específicos sobre cómo se manejan los datos de CC
• Hay TONELADAS de requisitos adicionales ... consulte la documentación a continuación

Además, su cliente AHORA puede ver si se rechazan las tarjetas y averiguar cómo manejar esas situaciones ... Mucho mejor cuando se toma la decisión de aprobar / rechazar en el momento de la compra.

Lo anterior es bastante genérico y asumo que es un negocio pequeño, así que iría a aquí para obtener más detalles . Lo más probable es que caigan en categoría D aquí , lo que significa que deberá trabajar con SAQ D v2.0 aquí .

Si su cliente no se ensucia después de entregarle el documento de PCI SAQ-D ... RUN.

Debería ser totalmente compatible con PCI-DSS, lo que costará órdenes de magnitud más de lo que costaría todo el proyecto. Estarían incumpliendo su acuerdo de servicios comerciales para tomar los datos electrónicamente sin el cumplimiento completo de PCI-DSS, lo que requiere que se cumpla con una larga lista de requisitos. Es simplemente demasiado complejo para el proyecto del que está hablando.

Para empezar, tendría que tener una red completamente segmentada que aísle el servidor de detalles de pago de cualquier otra cosa y tendría que volcar, de una forma, a una red aislada para el almacenamiento y uso de la información de la tarjeta de crédito. Esa información entonces tendría que ser extraída e ingresada manualmente para su procesamiento. Estamos hablando de meses de trabajo de desarrollador a tiempo completo para un desarrollador experto que sabe lo que están haciendo, por lo que es muy probable que esté hablando de un presupuesto de decenas de miles de dólares si es un trabajo de consultoría, solo para el formulario de pago, no para mencione los costos de hardware y red del hardware necesario.

Será mucho, mucho más barato para ellos usar una puerta de enlace comercial para proporcionar el procesamiento de la tarjeta de crédito, por no mencionar que es más rápido y más eficiente. En ese caso, pueden reenviar los detalles de la transacción a un proveedor de servicios de pago y simplemente obtener una confirmación del recibo del pago. Las tarifas no van a ser sustancialmente peores que las tarifas que pagarían por la tarjeta que no presente la transacción de todos modos.

Conozco a un pequeño proveedor que comenzó a tomar pedidos con tarjeta de crédito por teléfono en 1991. Los números se ingresaron manualmente en una PC con software POS que marca un número 800 de la red de la tarjeta a través de un módem, y aún se usa hasta el día de hoy. En 1996 abrieron un sitio web y comenzaron a capturar números de tarjetas en formularios de pedido con HTTP simple, que el servidor simplemente guarda en un archivo de texto. Esos pedidos se copian manualmente y se ingresan en el POS. En 2011, un empleado descargó e instaló un pequeño servidor SSL en un bloc de notas de $ 275, solo para que tuvieran algo de qué servir en la página del formulario de pedido (porque los clientes seguían pidiendo HTTPS para "asegurar" sus pedidos), de lo contrario, sus operaciones siguen siendo el objetivo. mismo. Solo hacen un puñado de pedidos de tarjetas de crédito por día, y no usan la red para procesar tarjetas. PCI no los molesta, y no se preocupan por PCI, y sus costos de desarrollo han sido muy bajos, pero son conscientes de sus datos y les confío mi tarjeta mucho más que el típico restaurante o gas. estación.

Hasta ahora, todas las respuestas están mirando el panorama general de lo que podría hacerse con los datos después de la transmisión segura de un número de tarjeta de crédito a su cliente, por lo que esas respuestas se centran en todos los detalles aterradores sobre la seguridad y el cumplimiento posteriores. Sin embargo, para responder a la pregunta real que formuló, que solo pregunta sobre la transmisión segura desde un formulario web, necesitará un servidor (o servicio) SSL, que está ampliamente disponible, y en forma mínima puede ser solo un puñado de líneas de código corriendo en un teléfono o una libreta. Eso protege el número de tarjeta en su camino desde el formulario web a su máquina (al igual que poner el pulgar sobre su número de tarjeta lo protege de ser visto por todos los demás en el restaurante cuando le pasa su tarjeta a un camarero), pero una vez que la tarjeta el número llega a su servidor, la transmisión (y la protección SSL) han terminado y el servidor (u operador) puede hacer cualquier cosa con ese número (al igual que el camarero puede hacer cualquier cosa con su tarjeta una vez que la haya entregado).