Je sais qu'il ya eu de nombreux messages sur le stockage des informations de carte de crédit. Nous construisons une application mobile et que les gens soient en mesure d'entrer dans leurs informations de carte une fois, et non à chaque achat.
Nous avons examiné Authorize.net CIM , et il semble être une solution idéale (nous stockons juste un ID de profil ou d'un jeton qui retourne le numéro de carte de crédit) ... mais il pourrait tomber en deçà de nos besoins, étant donné que les informations de carte de crédit ne sont pas traitées (nécessairement) par authorize.net mais quel que soit le compte marchand nous envoyons le paiement aussi. Autrement dit, nous voulons stocker les informations de carte de crédit comme un porte-monnaie ... pas nécessairement traiter avec Authorize.net chaque fois.
Lecture de la CIM documentation XML (p.94), il semble que le getCustomerPaymentProfileResponse masque les données de retour de carte de crédit ... donc je ne vois pas comment cela pourrait être utile pour le traitement si les données sont masquées?
Nous avons d'autres options pour la mise en œuvre, mais j'ai été vraiment l'espoir d'avoir un moyen basé sur le Web pour les clients de gérer leurs comptes de paiement. Est-ce que quelqu'un sait de toute façon de stocker des données de carte de crédit qui peuvent être appelées à la demande à transmettre au processeur de tout commerçant donné?
EDIT 28/04/2011 - je frappe un mur avec cela. Et si on ne passe pas stocker les informations de carte de crédit à tous, ont des clients entrent et il ... comment pouvons-nous le faisons en toute sécurité? Pas de stocker, transmettre HTTPS, crypter les données de carte en transit?
3 Réponses :
Si ces marchands / vendeurs sont disposés à modifier leur API, je vais regarder la tokénisation de la carte. C'est une fonctionnalité offerte par certains processeurs qui vous permet de transiger des paiements sans numéro de carte. La façon dont ces travaux sont sur la première transaction, l'utilisateur remet ses informations sur la carte au processeur, qui transmet un jeton au commerçant qui identifie de manière unique les données de titulaire de la carte pour cet utilisateur et cet intervenant, et les données de cartes de l'utilisateur sont stockées en interne par le processeur. .
Vous pouvez ensuite stocker ces jetons et les transmettre aux applications de paiement du fournisseur, qui les utiliseraient à son tour pour traiter les transactions. Je suppose que ces jetons seraient uniques à un marchand spécifique. Vous devrez donc probablement stocker 1 jeton par fournisseur / marchand pour un utilisateur spécifique.
Il y a peut-être une règle à ce sujet, où le vendeur / marchand ne peut pas les jetons de proxy ou les obtenir autrement d'un tiers. Si tel est le cas, vos vendeurs pourraient fournir un nouveau jeton / GUID qui correspond au jeton qu'ils stockent en interne pour une utilisation avec leur processeur de cartes ...
Google - Tobenisation de carte de crédit
PCI-DSS n'est pas une blague, et bien que ces marchands / vendeurs ne nécessitent pas techniquement de divulguer à leur processeur que votre application stocke des numéros de carte, mais si elles le divulguent, cela pourrait devenir désordonné. L'une des deux choses pourrait arriver:
Je viens de réaliser qu'Autorize.net CIM est une sorte de service de jobnisation. Donc, vous êtes probablement au courant de la majeure partie de cela. Je vais laisser le message ici même s'il est peut-être utile pour quelqu'un d'autre.
Merci ... En fait, j'ai trouvé plus tard que la tokénisation est la même chose. J'ai contacté quelques vendeurs et ils ont principalement accepté le commentaire de Paulg selon lequel nous devrions traiter à travers leurs comptes marchands. Je serais peut-être à penser à une autre façon de gérer cela.
C'est une idée cool de ce que vous proposez, alors bonne chance! Le seul problème que je peux prévoir avec le passage de ces jetons autour de ces jetons est si les jetons sont compromis et que le commerçant les accepte de l'extérieur de votre application et / ou sans sorte de contexte authentifié, le pire qu'un attaquant pouvait assumer une adresse d'expédition / facturation est Lié au jeton est d'acheter et d'expédier avec moi un tas de choses que je ne veux pas - ce qui pourrait être mauvais - je serais contrarié - mais ce serait moins grave que les données de la carte volées.
Malheureusement, il n'y a pas de moyen facile d'y parvenir.
Comme vous le savez, les fournisseurs de services de paiement stockeront de manière sécurisée les détails de la carte et renvoient un identifiant de jeton (afin que vous puissiez faire référence à ces détails), mais ils ne peuvent jamais retourner les détails de la carte d'origine à vous.
C'est parce que la PSP aura parcouru la conformité PCI-DSS. Une partie de cette conformité veille à ce que les détails de la carte soient passés (tels que les autres partis 3e parties) sont également compatibles PCI-DSS. S'ils permettent de renvoyer les détails de la carte de la voûte au client, ils auraient donc besoin de s'assurer que le Client est également conforme à PCI-DSS (qui vaincre à peu près le point du client. en utilisant un fournisseur de services de paiement!).
Vos options sont donc:
- Travailler via la conformité PCI-DSS afin que vous puissiez stocker les détails de la carte en toute sécurité vous-même.
- stocker les détails de la carte à chaque fournisseur de services de paiement que vous interagez avec et stockez les jetons retournés de chacun.
Stripe fait quelque chose comme ça. Ils traitent les détails de la carte sans que vous n'ayez jamais besoin de les stocker et de vous remettre un jeton représentant la carte de crédit que vous pouvez alors:
Il y a un bon railscast sur la facturation avec la bande qui vaut la peine de vérifier. Très développeur sympathique.
D'accord - C'est la meilleure solution que nous avons utilisée en termes de convivialité du développement. Nous l'avons utilisé pour des dons, des accusations récurrentes et même un système de facturation client complète pour les frais ponctuels et récurrents, non provenant d'une initiation client SaaS. Leur API a certaines hypothèses qui rendent certaines fonctions plus difficiles - mais globalement est la plus facile et la plus fiable que nous avons intégrée. L'authentification de jeton est actuellement la voie à suivre.
Est-ce qu'ils vous permettent de mettre des détails de carte de crédit sur une popup hébergée comme autorisé.net cim?
Oui, je suis d'accord que la chose Sony était très opportune. Je n'ai aucun désir de stocker les informations dans nos bases de données .... Way to Risky IMO.
Juste une suggestion. Ne stockez pas ces informations sur le téléphone lui-même. Si vous le stockez sur un site Web afin que vos clients puissent gérer un profil client, assurez-vous d'investir dans le certificat SSL. Je verrais même comme seulement en collectant ce dont vous avez besoin de sorte que ce qui arrive à Sony n'arrive pas à votre entreprise.
Quant à votre question, je contacterais simplement le personnel d'assistance autorisée.net pour être honnête. Ce que vous ne voulez pas faire, c'est stocker des informations complètes de carte de crédit à moins que vous ne l'iez. Assurez-vous de permettre au client uniquement le choix de sauver les informations. J'ai toujours pensé que la plupart des vendeurs ont simplement enregistré le numéro d'autorisation lorsqu'il s'agit de ce type d'informations après la première transaction.
Oui, le problème est que nous allons nous intégrer à plusieurs fournisseurs différents ... dépend vraiment de l'endroit où l'application est utilisée. Donc, je suis vraiment seulement besoin de la partie de stockage, pas de la partie de traitement.
Si c'était moi, je travaillerais avec votre processeur. Par exemple, la solution autorisée.net semble idéal si vous les traitées. Et votre processeur peut avoir des exigences spécifiques à ce sujet. Donc, je les contacterais.
@Jonathan malheureusement que cela ne fonctionnera pas avec notre modèle commercial à moins que nous stockions nos clients des informations de carte de crédit dans tous les processeurs concevables ... et même je ne sais pas si cela fonctionne depuis que nous ne sommes même pas les principaux responsables des comptes