Procesadores de pago - ¿Qué necesito saber si quiero aceptar tarjetas de crédito en mi sitio web? [cerrado]

Hágase la siguiente pregunta: ¿por qué desea almacenar los números de tarjetas de crédito en primer lugar? De hecho, si los almacena y logra que le roben uno, podría estar buscando una responsabilidad grave.

He escrito una aplicación que almacena números de tarjetas de crédito (ya que las transacciones se procesaron sin conexión). Aquí hay una buena manera de hacerlo:

• Obtener un certificado SSL!
• Crear un formulario para obtener CC# de la usuario.
• Cifrar parte (no todos!) del CC# y almacenarlo en su base de datos. (Sugeriría los 8 dígitos del medio.) Utilice un método de cifrado fuerte y una clave secreta.
• Envíe el resto del CC# a quien procese sus transacciones (probablemente usted mismo) con el ID de la persona a procesar.
• Cuando inicie sesión más tarde, escribirá el ID y la parte enviada por correo del CC#. Su sistema puede descifrar la otra parte y recombinar para obtener el número completo para que pueda procesar la transacción.
• Finalmente, elimine el registro en línea. Mi solución paranoica fue sobrescribir el registro con datos aleatorios antes de eliminarlo, para eliminar la posibilidad de un undelete.

Esto suena como mucho trabajo, pero al nunca grabar un CC# completo en ningún lugar, hace que sea extremadamente difícil para un hacker encontrar algo de valor en su servidor web. Confía en mí, vale la pena la tranquilidad.

El documento PCI 1.2 acaba de salir. Proporciona un proceso sobre cómo implementar el cumplimiento de PCI junto con los requisitos. Puede encontrar el documento completo aquí:

Https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

En resumen, cree un segmento de red separado para los servidores que se dedicarán a almacenar información CC (generalmente servidores DB). Aislar los datos tanto como sea posible, y garantizar solo el acceso mínimo necesario para acceder a los datos está presente. Cifrarlo cuando se almacena. Nunca almacene Pan's. Purgue los datos antiguos y gire sus claves de cifrado.

Ejemplo No hacer:

• No permita que la misma cuenta que puede buscar información general en la base de datos busque información CC.
• No mantenga su base de datos CC en el mismo servidor físico que su servidor web.
• No permita el tráfico externo (Internet) en su segmento de red de base de datos CC.

Ejemplo Dos:

• Utilice una base de datos separada cuenta para consultar la información de CC.
• No permitir todo el tráfico, excepto el requerido, al servidor de base de datos CC a través de firewall / listas de acceso
• Restrinja el acceso al servidor CC a un conjunto limitado de usuarios autorizados.

Me gustaría añadir un comentario no técnico que tal vez desee pensar

Varios de mis clientes ejecutan sitios de comercio electrónico, incluyendo un par que tienen tiendas moderadamente grandes. Ambos, aunque ciertamente podrían implementar una pasarela de pago que no elija demasiado, toman el número cc, lo almacenan temporalmente encriptado en línea y lo procesan manualmente.

Lo hacen debido a la alta incidencia de fraude y el procesamiento manual les permite tomar controles adicionales antes llenar un pedido. Me dicen que rechazan un poco más del 20% de todas sus transacciones: el procesamiento manual ciertamente toma tiempo adicional y en un caso tienen un empleado que no hace más que procesar transacciones, pero el costo de pagar su salario es aparentemente menor que su exposición si acaban de pasar los números cc a través de una puerta de enlace en línea.

Ambos clientes están entregando bienes físicos con valor de reventa, por lo que están particularmente expuestos y para artículos como software donde un la venta fraudulenta no daría lugar a ninguna pérdida real su kilometraje variaría, pero vale la pena considerar por encima de los aspectos técnicos de una puerta de enlace en línea si la implementación de tal es realmente lo que desea.

EDITAR: Y desde la creación de esta respuesta me gustaría añadir un cuento con moraleja y decir que el tiempo ha pasado cuando esto era una buena idea.

¿Por qué? Porque sé de otro contacto que estaba tomando un enfoque similar. Los detalles de la tarjeta se almacenaron encriptados, el sitio web fue accedido por SSL, y los números se eliminaron inmediatamente después del procesamiento. ¿Seguro crees?

Ninguna máquina en su red se infectó por un troyano de registro de claves. Como resultado, fueron identificados como la fuente de varias falsificaciones de tarjetas de crédito de score , y en consecuencia se vieron afectados por una gran multa.

Como resultado de esto, ahora nunca aconsejo a nadie que maneje tarjetas de crédito por sí mismo. Las pasarelas de pago se han vuelto mucho más competitivas y rentables, y el fraude las medidas han mejorado. El riesgo ya no vale la pena.

Podría eliminar esta respuesta, pero creo que lo mejor es dejarlo editado como un cuento con moraleja.

Tenga en cuenta que usar SSL para enviar un número de tarjeta desde un navegador a un servidor es como cubrir su número de tarjeta de crédito con su pulgar cuando entrega su tarjeta a un cajero en un restaurante: su pulgar (SSL) evita que otros clientes en el restaurante (la Red) vean la tarjeta, pero una vez que la tarjeta está en manos del cajero (un servidor web) la tarjeta ya no está protegida por el intercambio SSL, y el cajero podría estar haciendo cualquier cosa con esa tarjeta. El acceso a un número de tarjeta guardado puede solo ser detenido por la seguridad en el servidor web. Es decir, la mayoría de los robos de tarjetas en la red no se realizan durante la transmisión, se realizan al romper la mala seguridad del servidor y robar bases de datos.

¿Por qué molestarse con el cumplimiento de PCI?? En el mejor de los casos, te ahorrarás una fracción de un porcentaje en tus tarifas de procesamiento. Este es uno de esos casos en los que tienes que estar seguro de que esto es lo que quieres hacer con tu tiempo, tanto por adelantado en el desarrollo y con el tiempo para mantenerse al día con los últimos requisitos.

En nuestro caso, tenía más sentido usar una puerta de enlace con suscripción y emparejarla con una cuenta de comerciante. La pasarela de suscripción savy le permite omitir todo el cumplimiento de PCI y hacer nada más que procesar la transacción propiamente dicha.

Utilizamos TrustCommerce como nuestra puerta de enlace y estamos contentos con su servicio/precios. Tienen código para un montón de idiomas que hace que la integración sea bastante fácil.

Asegúrese de tener un control sobre el trabajo adicional y el presupuesto requerido para PCI. PCI puede requerir enormes honorarios de auditoría externa y esfuerzo/apoyo interno. También tenga en cuenta las multas/sanciones que se le pueden imponer unilateralmente, a menudo enormemente desproporcionadas a la escala de la "ofense".

Hay mucho en todo el proceso. La forma más fácil de hacerlo es usar servicios similares a paypal, para que nunca maneje los datos de la tarjeta de crédito. Aparte de eso, hay un poco de cosas que pasar para obtener la aprobación para ofrecer servicios de tarjeta de crédito en su sitio web. Probablemente debería hablar con su banco y las personas que emiten su identificación de comerciante para ayudarlo a configurar el proceso.

Como otros han mencionado, la forma más fácil de entrar en esta área es con el uso de Paypal, Google checkout o Nochex. Sin embargo, si tiene la intención de una cantidad significativa de negocios, es posible que desee buscar" actualizar " a servicios de integración de sitios de nivel superior como WorldPay, NetBanx (UK) o Neteller (US) . Todos estos servicios son razonablemente fáciles de configurar. Y sé que Netbanx ofrece una integración conveniente en algunos de los shelf shopping cart solutions como Intershop (porque escribí algunas de ellas). Más allá de eso, está buscando la integración directa con los sistemas bancarios (y sus sistemas APAX), pero eso es difícil y en ese momento también debe demostrar a las compañías de tarjetas de crédito que está manejando los números de tarjetas de crédito de forma segura (probablemente no vale la pena considerar si no está tomando worth 100k por mes).

Trabajando desde el primero hasta el último, los costos / beneficios son que las opciones tempranas son mucho más fácil (más rápido/más barato) de configurar puesto que paga cargos de manejo bastante altos para cada transacción. los últimos son mucho más costosos de configurar, pero paga menos a largo plazo.

La otra ventaja de la mayoría de las soluciones no dedicadas es que no necesita mantener seguros los números de tarjetas de crédito cifrados. Ese es el problema de otra persona: -)