2008-09-09 8 views
249

This question habla sobre diferentes procesadores de pago y lo que cuestan, pero estoy buscando la respuesta a lo que debo hacer si quiero aceptar pagos con tarjeta de crédito.Procesadores de pago: ¿qué debo saber si deseo aceptar tarjetas de crédito en mi sitio web?

Supongo que necesito tienda números de tarjeta de crédito para los clientes, por lo que la solución obvia de confiar en el procesador de tarjeta de crédito para hacer el trabajo pesado no está disponible.

PCI Data Security, que es aparentemente el estándar para almacenar información de tarjeta de crédito, tiene un montón de requisitos generales, pero how does one implement them?

¿Y qué pasa con los proveedores, como Visa, que tienen sus propias mejores prácticas?

¿Necesito tener acceso de llavero a la máquina? ¿Qué hay de protegerlo físicamente de los piratas informáticos en el edificio? ¿O qué pasa si alguien tiene en sus manos los archivos de copia de seguridad con los archivos de datos del servidor sql?

¿Qué ocurre con las copias de seguridad? ¿Hay otras copias físicas de esos datos?

Consejo: If you get a merchant account, you should negotiate that they charge you "interchange-plus" instead of tiered pricing. Con precios por niveles, le cobrarán tarifas diferentes según el tipo de Visa/MC que se utilice, es decir. te cobran más por las tarjetas con grandes recompensas asociadas a ellas. Interchange plus billing significa que solo le paga al procesador lo que Visa/MC le cobra, más una tarifa plana. (Amex y Discover cargan sus propias tarifas directamente a los comerciantes, por lo que esto no se aplica a esas tarjetas. Encontrará que las tasas Amex están en el rango del 3% y Discover podría ser tan bajo como el 1%. Visa/MC está en el rango del 2%). This service is supposed to do the negotiation for you (no he usado, esto no es un anuncio, y no estoy afiliado con el sitio web, pero este servicio es muy necesaria.)

Esta entrada de blog da una complete rundown of handling credit cards (específicamente para el Reino Unido) .


Tal vez redactadas de la pregunta equivocada, pero estoy en busca de consejos como éstos:

  1. Uso SecurID o eToken para añadir una capa de contraseña adicional a la caja física.
  2. Asegúrese de que la caja esté en una habitación con una combinación de bloqueo físico o código de tecla.
+0

Esto ha sido desaprobado por PA-DSS 2.0. –

Respuesta

231

Fui a través de este proceso no hace mucho tiempo con una empresa que trabajaba para y planeo ir a través de él de nuevo pronto con mi propio negocio. Si tiene algún conocimiento técnico de red, realmente no es tan malo. De lo contrario, será mejor que use Paypal u otro tipo de servicio.

El proceso comienza obteniendo una configuración de merchant account y vinculada a su cuenta bancaria. Es posible que desee consultar con su banco, ya que muchos de los principales bancos ofrecen servicios comerciales. Es posible que pueda obtener ofertas, porque ya es cliente suyo, pero si no, puede darse una vuelta. Si planea aceptar Discover o American Express, estos serán separados, ya que proporcionan los servicios comerciales para sus tarjetas, no se puede evitar esto. Hay otros casos especiales también. Este es un proceso de solicitud, esté preparado.

A continuación querrá comprar un certificado SSL que puede usar para proteger sus comunicaciones cuando la información de la tarjeta de crédito se transmite a través de redes públicas. Hay muchos vendedores, pero mi regla de oro es elegir uno que sea una marca de alguna manera. Cuanto mejor se conocen, mejor es probable que su cliente haya oído hablar de ellos.

A continuación puede encontrar un payment gateway para usar con su sitio. Aunque esto puede ser opcional dependiendo de qué tan grande sea, pero la mayoría de las veces no lo será. Necesitarás uno. Los proveedores de pasarela de pago proporcionan una forma de hablar con la API de Internet Gateway con la que se comunicará. La mayoría de los proveedores proporcionan comunicación HTTP o TCP/IP con su API. Procesarán la información de la tarjeta de crédito en su nombre. Dos proveedores son Authorize.Net y PayFlow Pro. El enlace que proporciono a continuación tiene más información sobre otros proveedores.

¿Ahora qué? Para empezar, hay pautas sobre a qué debe adherirse su aplicación para transmitir las transacciones. Durante el proceso de configurar todo, alguien revisará su sitio o aplicación y se asegurará de cumplir con los lineamientos, como usar SSL y que tiene términos de uso y documentación de políticas sobre qué información se utiliza. para. No robar esto de otro sitio. Crea el tuyo, contrata a un abogado si es necesario. La mayoría de estas cosas caen bajo el enlace de PCI Data Security que Michael proporcionó en su pregunta.

Si planea almacenar los números de tarjetas de crédito, entonces es mejor estar preparado para poner algunas medidas de seguridad internas a fin de proteger la información. Asegúrese de que el servidor en el que está almacenada la información solo sea accesible para los miembros que necesitan tener acceso. Como cualquier buena seguridad, haces cosas en capas. Cuantas más capas pongas, mejor. Si lo desea, puede utilizar la seguridad del tipo llavero, como SecureID o eToken para proteger la habitación en la que se encuentra el servidor. Si no puede pagar la ruta del llavero, utilice el método de dos llaves. Permita que una persona que tenga acceso a la sala firme una clave, que acompaña a la clave que ya tienen. Necesitarán ambas llaves para acceder a la habitación.A continuación, protege la comunicación al servidor con políticas. Mi política es que lo único que se comunica a través de la red es la aplicación y esa información está encriptada. El servidor no debe ser accesible de ninguna otra forma. Para las copias de seguridad, utilizo truecrypt para cifrar los volúmenes en los que se guardarán las copias de seguridad. Cada vez que los datos se eliminan o se almacenan en otro lugar, de nuevo se usa truecrypt para encriptar el volumen en el que están los datos. Básicamente, donde sea que estén los datos, es necesario que estén encriptados. Asegúrese de que todos los procesos para obtener los datos tengan pistas de auditoría. use registros para acceder a la sala del servidor, use cámaras si puede, etc. Otra medida es encriptar la información de la tarjeta de crédito en la base de datos. Esto asegura que los datos solo se puedan ver en su aplicación donde puede hacer cumplir quién ve la información.

Uso pfsense para mi firewall. Lo ejecuto en una tarjeta flash compacta y tengo dos servidores configurados. Una es para el fail over para la redundancia.

Encontré este blog post de Rick Strahl, que me ayudó enormemente a entender cómo hacer el comercio electrónico y qué se necesita para aceptar tarjetas de crédito a través de una aplicación web.

Bueno, esta resultó ser una respuesta larga. Espero que estos consejos ayuden.

+13

Respuesta perfecta. Espero que otros se sumen. –

+3

Uno de los mejores que he visto ... +1 –

+2

@Michael Pryor: Si es tan perfecto, ¿por qué otros necesitan agregarse? Huh ??? – donut

2

Hay mucho en todo el proceso. La forma más fácil de hacerlo es usar servicios similares a PayPal, para que nunca maneje realmente ningún dato de tarjeta de crédito. Además de eso, hay un montón de cosas que hacer para obtener la aprobación para ofrecer servicios de tarjetas de crédito en su sitio web. Probablemente deba hablar con su banco y las personas que emiten su identificación de comerciante para ayudarlo a configurar el proceso.

2

Como otros han mencionado, la forma más fácil de hacerlo es con el uso de Paypal, Google checkout o Nochex. Sin embargo, si tiene la intención de realizar una cantidad significativa de negocios, puede 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 algunas de las soluciones de carrito de compras listas para usar, 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 maneja los números de tarjetas de crédito de forma segura (probablemente no valga la pena no está tomando $ 100k vale por mes).

Trabajando desde el 1 de durar los costos/beneficios son que las primeras opciones son mucho más fáciles (más rápido/más barato) para establecer puesto que paga cargas muy altas de manejo para cada transacción. las últimas son mucho más costosas de configurar, pero pagas 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 tarjeta de crédito cifrados. Eso es problema de otra persona :-)

22

Hazte la siguiente pregunta: ¿por qué quieres almacenar números de tarjetas de crédito en primer lugar? Es probable que no lo haga. De hecho, si los almacena y logra que se los roben, podría estar viendo serias responsabilidades.

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

  • ¡Obtenga un certificado SSL!
  • Crea un formulario para obtener CC# del usuario.
  • Encripte la parte (no todas!) Del CC# y guárdela en su base de datos. (Sugeriría los 8 dígitos del medio.) Use un método de encriptación fuerte y una clave secreta.
  • Envíe el resto del CC# a quienquiera que procese sus transacciones (probablemente usted mismo) con la identificación de la persona a procesar.
  • Cuando inicie sesión más tarde, ingrese la ID y la porción enviada por correo del CC#. Su sistema puede descifrar la otra parte y recombinarse 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 la eliminación, para eliminar la posibilidad de una recuperación.

Esto suena como un montón de trabajo, pero al no registrar un CC# completo en ninguna parte, 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.

+1

Mira el comentario que Michael dejó para Sam Wessel a continuación. –

17

Acaba de salir el documento PCI 1.2. 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

Para resumir, crear un segmento de red diferente para lo que serán dedicados servidores de almacenar información de CC (por lo general servidor (s) DB). Aísle los datos tanto como sea posible y asegúrese de que solo esté presente el acceso mínimo necesario para acceder a los datos. Cifrelo cuando lo guarde. Nunca almacene PAN's. Purgue los datos antiguos y gire sus claves de cifrado.

Ejemplo qué no hacer:

  • No deje que la misma cuenta que puede buscar información general en la base de datos de buscar información de 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:

  • utilizar una cuenta de base de datos independiente para consultar información de CC.
  • Deshabilitar todo el tráfico, excepto el requerido para el servidor de base de datos CC a través de firewall/access-lists
  • Restringir el acceso al servidor CC a un conjunto limitado de usuarios autorizados.
+5

Tenga en cuenta que los requisitos de PCI-DSS se aplican a todos los sistemas que los datos de la tarjeta * pasan por * y no solo donde están * almacenados *. Por lo tanto, las mismas restricciones y requisitos de seguridad también se aplican al servidor web/servidor de aplicaciones (y a los sitios que pertenecen a todos los demás hosts en esas máquinas) y a todos los demás hosts en el mismo segmento de red que esas máquinas. – Cheekysoft

+0

Absolutamente cierto – Zak

13

Me gustaría añadir un comentario no técnica que es posible que desee pensar en

Varios de mis clientes ejecuta sitios de comercio electrónico, incluyendo una pareja que tiene moderadamente grandes almacenes. Ambos, si bien ciertamente podrían implementar una pasarela de pago, tampoco eligen, toman el número de cc, lo almacenan encriptado temporalmente 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 de completar un pedido. Me dijeron que rechazan un poco más del 20% de todas sus transacciones: el procesamiento manual lleva tiempo extra 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 el de ellos. exposición si acaban de pasar números de CC a través de una puerta de enlace en línea.

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

EDIT: Y desde que creé esta respuesta me gustaría agregar una historia de advertencia y decir que ya pasó el tiempo cuando esta era una buena idea.

¿Por qué? Porque sé de otro contacto que estaba tomando un enfoque similar. Los datos de la tarjeta se almacenaron encriptados, se accedió al sitio web mediante SSL y los números se eliminaron inmediatamente después del procesamiento. ¿Seguro que piensas?

Ninguna máquina en su red se ha infectado con un troyano de registro de claves. Como resultado, se los identificó como fuente de varias falsificaciones de tarjetas de crédito y, en consecuencia, recibieron una gran multa.

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

Podría eliminar esta respuesta, pero creo que es mejor dejarla editada como una historia de advertencia.

+1

Este es un comentario realmente útil, algo que nunca he considerado. Gracias – 0plus1

+0

Excelente, gracias. – SimplGy

5

¿Por qué molestarse con el cumplimiento de PCI? En el mejor de los casos, reducirá una fracción de un por ciento de sus tarifas de procesamiento.Este es uno de esos casos en los que debe asegurarse de que esto es lo que desea hacer con su tiempo tanto en el desarrollo como en el tiempo para mantenerse al día con los últimos requisitos.

En nuestro caso, tiene más sentido usar una puerta de enlace de suscripción-savy y vincularla con una cuenta de comerciante. El gateway de suscripción-savy le permite omitir todo el cumplimiento de PCI y no hacer nada más que procesar la transacción propiamente dicha.

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

+5

Una razón sería evitar que la puerta de enlace de pago lo tome como rehén, y si quiere cambiar a otra puerta de enlace, la puerta de enlace anterior probablemente no le dará acceso a toda la información de CC que tienen de sus clientes, lo que lo obligará a pregunte a los clientes los detalles de CC en la compra con la nueva puerta de enlace de pago. Vaya al paso 1. :) – Zabba

3

Asegúrese de controlar el trabajo extra y el presupuesto requerido para PCI. PCI puede requerir enormes tarifas de auditoría externa y esfuerzo/soporte interno. También tenga en cuenta las multas/sanciones que se le pueden imponer unilateralmente, a menudo enormemente desproporcionadas a la escala del 'delito'.

7

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 dedo pulgar cuando entrega su tarjeta a un cajero en un restaurante: su pulgar (SSL) previene otras clientes en el restaurante (la red) de ver 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 solo puede ser detenido por la seguridad en el servidor web. Es decir, la mayoría de los robos de tarjetas en la red no se llevan a cabo durante la transmisión, y se hacen rompiendo la deficiente seguridad del servidor y robando las bases de datos.

+0

Aquí es donde entra PCI DSS, es decir, no almacenando el PAN completo en el servidor. –

Cuestiones relacionadas