Processeurs de paiement-que dois-je savoir si je veux accepter les cartes de crédit sur mon site web? [fermé]
Cette question parle des différents processeurs de paiement et de leur coût, mais je cherche la réponse à ce que dois-je faire si je veux accepter les paiements par carte de crédit?
Supposons que je dois stocker les numéros de carte de crédit pour les clients, de sorte que la solution évidente de compter sur le processeur de carte de crédit pour faire le levage de charges lourdes n'est pas disponible.
PCI Data Security , qui est apparemment la norme pour stocker les informations de carte de crédit, a un tas de exigences générales, mais comment les implémente-t-on?
Et les vendeurs, comme Visa, qui ont leurs propres pratiques?
Dois-je avoir accès à la machine? Qu'en est-il de protéger physiquement contre les pirates dans le bâtiment? Ou même si quelqu'un a mis la main sur les fichiers de sauvegarde avec les fichiers de données sql server dessus?
Qu'en est-il des sauvegardes? Y a-t-il d'autres copies physiques de ces données autour?
Astuce: Si vous obtenez un compte marchand, vous devriez négocier qu'ils vous facturent "interchange-plus" au lieu de tarification à plusieurs niveaux. avec des prix échelonnés, ils vous factureront des taux différents en fonction du type de Visa / MC est utilisé-ie. ils vous facturent plus pour les cartes avec de grandes récompenses qui leur sont attachées. La facturation Interchange plus signifie que vous ne payez au processeur que les frais de Visa/MC, plus des frais fixes. (Amex et Discover facturent leurs propres tarifs directement aux commerçants, donc cela ne s'applique pas à ces cartes. Vous trouverez des taux Amex pour être dans la gamme 3% et Discover pourrait être aussi bas que 1%. Visa / MC est dans la gamme 2%). Ce service est censé faire la négociation pour vous (Je ne l'ai pas utilisé, ce n'est pas une annonce, et je ne suis pas affilié au site, mais ce service est grandement nécessaire.)
Cet article de blog donne un aperçu complet de la gestion des cartes de crédit (spécifiquement pour le Royaume-Uni).
Peut-être que j'ai mal formulé la question, mais je cherche conseils comme ceux-ci:
9 réponses
Je suis passé par ce processus il n'y a pas si longtemps avec une entreprise pour laquelle je travaillais et je prévois de le refaire bientôt avec ma propre entreprise. Si vous avez des connaissances techniques du réseau, ce n'est vraiment pas si mal. Sinon, vous feriez mieux d'utiliser Paypal ou un autre type de service.
Le processus commence par compte marchand configuration et lié à votre compte bancaire. Vous pouvez vérifier avec votre banque, parce que beaucoup de grandes banques fournissent marchand service. Vous pouvez être en mesure d'obtenir des offres, parce que vous êtes déjà un client de leur, mais sinon, alors vous pouvez magasiner. Si vous envisagez d'accepter Discover ou American Express, ceux-ci seront séparés, car ils fournissent les services marchands pour leurs cartes, Pas de contourner cela. Il y a d'autres cas spéciaux aussi. Ceci est un processus de demande, être prêt.
Ensuite, vous voulez acheter un certificat SSL {[6] } que vous pouvez utiliser pour sécuriser vos communications lorsque les informations de carte de crédit sont transmises sur les réseaux publics. Il y a beaucoup de fournisseurs, mais ma règle de base est de choisir celui qui est un nom de marque dans un sens. Plus ils sont connus, mieux votre client a probablement entendu parler d'eux.
Ensuite, vous voulez trouver un la passerelle de paiement à utiliser avec votre site. Bien que cela puisse être facultatif en fonction de la taille que vous êtes, mais la majorité du temps, il ne sera pas. Vous en aurez besoin. Les fournisseurs de passerelle de paiement fournissent un façon de parler à L'API Internet Gateway avec laquelle vous communiquerez. La plupart des fournisseurs fournissent une communication HTTP ou TCP/IP avec leur API. Ils traiteront les informations de carte de crédit en votre nom. Deux vendeurs sont Authorize.Net et PayFlow Pro. Le lien que je fournis ci-dessous a plus d'informations sur d'autres fournisseurs.
Maintenant? Pour commencer, il existe des directives sur ce que votre application doit respecter pour transmettre les transactions. Au cours du processus de pour tout configurer, quelqu'un regardera votre site ou votre application et s'assurera que vous respectez les directives, comme l'utilisation de SSL et que vous avez des conditions d'utilisation et de la documentation sur les informations que l'utilisateur vous donne. Ne pas voler cela à partir d'un autre site. Trouvez le vôtre, engagez un avocat si vous en avez besoin. La plupart de ces choses relèvent du lien de sécurité des données PCI fourni par Michael dans sa question.
Si vous prévoyez de stocker les numéros de carte de crédit, ensuite, vous feriez mieux d'être prêt à mettre en place des mesures de sécurité en interne pour protéger les informations. Assurez-vous que le serveur sur lequel les informations sont stockées n'est accessible qu'aux membres qui doivent y avoir accès. Comme toute bonne sécurité, vous faites les choses en couches. Plus vous mettez de couches en place, mieux c'est. Si vous le souhaitez, vous pouvez utiliser la sécurité de type key fob, comme SecureID ou eToken pour protéger la pièce dans laquelle se trouve le serveur. Si vous ne pouvez pas vous permettre l'itinéraire porte-clés, utilisez les deux clés méthode. Permettre à une personne qui a accès à la salle de signer une clé, qui va de pair avec une clé, ils portent déjà. Ils auront besoin des deux clés pour accéder à la pièce. Ensuite, vous protégez la communication avec le serveur avec des stratégies. Ma politique est que la seule chose qui lui communique sur le réseau est l'application et que les informations sont cryptées. Le serveur ne doit pas être accessible sous une autre forme. Pour les sauvegardes, j'utilise truecrypt pour chiffrer les volumes les sauvegardes seront enregistré. Chaque fois que les données sont supprimées ou stockées ailleurs, vous utilisez à nouveau truecrypt pour chiffrer le volume sur lequel les données sont activées. Fondamentalement, où que les données soient, elles doivent être cryptées. Assurez-vous que tous les processus pour obtenir les données portent des pistes d'audit. utilisez les journaux pour accéder à la salle des serveurs, utilisez des caméras si vous le pouvez, etc... Une autre mesure consiste à chiffrer les informations de carte de crédit dans la base de données. Cela garantit que les données ne peuvent être visualisées que dans votre application où vous le pouvez appliquer qui voit les informations.
J'utilise pfsense pour mon pare-feu. Je l'exécute sur une carte compact flash et j'ai deux serveurs configurés. L'un est pour le basculement pour la redondance.
J'ai trouvé ce blog post par Rick Strahl qui a énormément aidé à comprendre faire du commerce électronique et ce qu'il faut pour accepter les cartes de crédit via une application web.
Eh Bien, cela s'est avéré être une longue réponse. J'espère que ces conseils aider.
Posez-vous la question suivante: pourquoi voulez-vous stocker des numéros de carte de crédit en premier lieu? Les Chances sont que vous ne le faites pas. en fait, si vous Ne les stocker et réussir à se faire voler un, vous pourriez être à la recherche d'une responsabilité sérieuse.
J'ai écrit une application qui stocke les numéros de carte de crédit (puisque les transactions ont été traitées hors ligne). Voici une bonne façon de le faire:
- obtenez un certificat SSL!
- créez un formulaire pour obtenir CC# du utilisateur.
- chiffrer une partie (pas tous!) du CC# et le stocker dans votre base de données. (Je suggère les 8 chiffres du milieu.) Utilisez une méthode de cryptage forte et une clé secrète.
- envoyez le reste du CC# à celui qui traite vos transactions (probablement vous-même) avec L'ID de la personne à traiter.
- lorsque vous vous connecterez plus tard, vous taperez L'ID et la partie postée du#CC. Votre système peut déchiffrer l'autre partie et se recombiner pour obtenir le numéro complet afin que vous puissiez traiter la transaction.
- enfin, supprimez l'enregistrement en ligne. Ma solution paranoïaque était d'écraser l'enregistrement avec des données aléatoires avant la suppression, pour supprimer la possibilité d'un undelete.
Cela ressemble à beaucoup de travail, mais en n'enregistrant jamais un CC# complet n'importe où, il est extrêmement difficile pour un pirate de trouver quoi que ce soit de valeur sur votre serveur web. Croyez-moi, ça vaut la peine d'avoir l'esprit tranquille.
Le document PCI 1.2 vient de sortir. Il donne un processus pour la mise en œuvre de la conformité PCI avec les exigences. Vous pouvez trouver le document complet ici:
Https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Bref, créez un segment réseau distinct pour les serveurs qui seront dédiés au stockage des informations CC (généralement des serveurs DB). Isoler les données autant que possible, et assurer seulement le minimum d'accès nécessaire pour accéder aux données est présent. Chiffrer quand vous le stockez. Ne jamais stocker DE PAN. purger les anciennes données et faire pivoter vos clés de chiffrement.
Exemple à ne pas faire:
- Ne laissez pas le même compte qui peut rechercher des informations générales dans la base de données rechercher des informations CC.
- ne conservez pas votre base de données CC sur le même serveur physique que votre serveur web.
- n'autorisez pas le trafic externe (Internet) dans votre segment de réseau de base de données CC.
Exemple Dos:
- utiliser une base de données distincte compte pour interroger les informations CC.
- interdire tout le trafic requis vers le serveur de base de données CC via des pare-feu/listes d'accès
- restreindre L'accès au serveur CC à un nombre limité d'utilisateurs autorisés.
J'aimerais ajouter un commentaire non technique auquel vous voudrez peut-être réfléchir
Plusieurs de mes clients gèrent des sites de commerce électronique, y compris un couple qui a des magasins modérément grands. Les deux, alors qu'ils pourraient certainement mettre en œuvre une passerelle de paiement ne choisissent pas trop, ils prennent le numéro cc, Le stockent temporairement crypté en ligne et le traitent manuellement.
ILS le font en raison de la forte incidence de la fraude et le traitement manuel leur permet de prendre des contrôles supplémentaires avant répondant à une commande. On me dit qu'ils rejettent un peu plus de 20% de toutes leurs transactions - le traitement manuel prend certainement plus de temps et dans un cas, ils ont un employé qui ne fait que traiter les transactions, mais le coût de payer son salaire est apparemment inférieur à leur exposition s'ils viennent de passer des numéros cc via une passerelle
Ces deux clients livrent des biens physiques ayant une valeur de revente, ils sont donc particulièrement exposés et pour des articles tels que des logiciels où un la vente frauduleuse n'entraînerait aucune perte réelle votre kilométrage varierait, mais il vaut la peine de considérer ci-dessus les aspects techniques d'une passerelle en ligne si la mise en œuvre est vraiment ce que vous voulez.
EDIT: et depuis la création de cette réponse, j'aimerais ajouter une mise en garde et dire que le temps est passé où c'était une bonne idée.
Pourquoi? Parce que je connais un autre contact qui adoptait une approche similaire. Les détails de la carte ont été stockés cryptés, le site a été consulté par SSL, et les numéros ont été supprimés immédiatement après le traitement. Sécurisé vous pensez?
Aucune machine sur leur réseau n'a été infectée par un cheval de Troie de journalisation de clé. En conséquence, ils ont été identifiés comme étant la source de plusieurs faux de carte de crédit score - et ont donc été touchés par une amende importante.
À la suite de cela, je ne conseille jamais à quiconque de gérer les cartes de crédit eux-mêmes. Les passerelles de paiement sont depuis devenues beaucoup plus compétitives et rentables, et la fraude les mesures se sont améliorées. Le risque est maintenant n'est plus la peine.
Je pourrais supprimer cette réponse, mais je pense qu'il vaut mieux laisser édité comme un récit édifiant.
Gardez à l'esprit que L'utilisation de SSL pour envoyer un numéro de carte d'un navigateur à un serveur est comme couvrir votre numéro de carte de crédit avec votre pouce lorsque vous remettez votre carte à un caissier dans un restaurant: votre pouce (SSL) empêche les autres clients du restaurant (le Net) de voir la carte, mais une fois que la carte est entre les mains du caissier (un serveur web) la carte n'est plus protégée par L'échange SSL, et le caissier pourrait faire n'importe quoi avec cette carte. L'accès à un numéro de carte enregistré peut seulement être arrêté par la sécurité sur le serveur web. C'est-à-dire que la plupart des vols de cartes sur le net ne se font pas pendant la transmission, ils se font en brisant la sécurité du serveur et en volant des bases de données.
Pourquoi s'embêter avec la conformité PCI?? Au mieux, vous raser une fraction d'un pour cent de vos frais de traitement. C'est l'un de ces cas où vous devez être sûr que c'est ce que vous voulez faire avec votre temps à la fois dès le départ dans le développement et au fil du temps en suivant les dernières exigences.
Dans notre cas, il était le plus logique d'utiliser une passerelle d'abonnement et de la coupler avec un compte marchand. La passerelle abonnement-savy vous permet d'ignorer toute la conformité PCI et de faire rien de plus que de traiter la transaction proprement dite.
Nous utilisons TrustCommerce comme passerelle et sommes satisfaits de leur service/prix. Ils ont du code pour un tas de langues qui rend l'intégration assez facile.
Assurez-vous d'obtenir une poignée sur le travail supplémentaire et le budget requis pour PCI. PCI peut exiger d'énormes frais d'audit externe et effort/soutien interne. Soyez également conscient des amendes / pénalités qui peuvent vous être imposées unilatéralement, souvent extrêmement disproportionnées par rapport à l'échelle de l'ofense.
Il y a beaucoup à tout le processus. La seule façon la plus simple de le faire est d'utiliser des services similaires à paypal, de sorte que vous ne manipulez jamais les données de carte de crédit. En dehors de cela, il y a un peu de choses à passer pour obtenir approuvé pour offrir des services de carte de crédit sur votre site web. Vous devriez probablement parler avec votre banque, et les personnes qui émettent votre ID marchand pour vous aider à mettre en place le processus.
Comme d'autres l'ont mentionné le moyen le plus facile dans ce domaine est avec l'utilisation de Paypal, Google checkout ou Nochex. Cependant, si vous avez l'intention d'une quantité importante d'affaires, vous pouvez rechercher" mise à niveau " vers des services d'intégration de sites de niveau supérieur tels que WorldPay, NetBanx (UK) ou Neteller (US). Tous ces services sont raisonnablement faciles à mettre en place. Et je sais que Netbanx offre une intégration pratique dans certains des off the étagère panier des solutions telles que Intershop (parce que j'ai écrit certains d'entre eux). Au-delà de cela, vous envisagez une intégration directe avec les systèmes bancaires (et leurs systèmes APAX), mais c'est difficile et à ce moment-là, vous devez également prouver aux sociétés de cartes de crédit que vous manipulez les numéros de carte de crédit en toute sécurité (probablement pas la peine d'envisager si vous ne prenez pas 100k $ par mois).
Travailler du 1er au dernier les coûts / avantages sont que les premières options sont beaucoup plus facile (plus rapide/moins cher) à mettre en place, vous payez des frais de manutention assez élevés pour chaque transaction. les derniers sont beaucoup plus coûteux à mettre en place, mais vous payez moins à long terme.
L'autre avantage de la plupart des solutions non dédiées est que vous n'avez pas besoin de garder les numéros de carte de crédit cryptés en toute sécurité. C'est le problème de quelqu'un d'autre: -)