Sécurité et données de carte
Encaisser des paiements dans Salesforce soulève les questions que se pose tout administrateur et tout auditeur : où vont les numéros de carte, qu’est-ce qui est stocké, qui peut voir quoi, et que devons-nous faire nous-mêmes ? Cet article y répond pour REDA Pay 1.56 tel qu’il est conçu, et liste les responsabilités qui restent les vôtres.
Ce qui n’est jamais stocké dans Salesforce
| Donnée | Traitement |
|---|---|
| Numéro de carte complet (PAN) | Jamais écrit dans un enregistrement Salesforce. Après l’enregistrement, seuls la marque, le type, le mois et l’année d’expiration, le nom du titulaire et le code postal de la carte sont conservés, et le nom du moyen affiche les quatre derniers chiffres |
| Code de sécurité de la carte (CVV/CVC) | Jamais stocké |
| Numéro de compte bancaire complet | Jamais stocké. Le routing number, le type, la classe, la devise, le nom du titulaire et les derniers chiffres (dans le nom) sont conservés |
Ce qui est stocké chiffré
REDA Pay chiffre ces éléments avec une clé générée une fois dans votre organisation et jamais affichée ; consultez Générer la clé de chiffrement :
- le jeton API Payload du Pay Profile ;
- les identifiants Payload de votre organisation (Profile Id), de chaque compte commerçant, de chaque client et de chaque moyen de paiement enregistré (le jeton que Payload utilise à la place de la carte ou du compte) ;
- l’identifiant contenu dans chaque lien de paiement.
Une personne qui peut lire ces enregistrements voit un texte chiffré. L’identifiant de transaction de Payload est stocké en clair, car c’est un numéro de référence utilisé dans les échanges avec le support et il ne contient aucun secret.
Comment circulent les informations de carte et de banque
Sur les écrans de paiement et d’enregistrement de moyen, le payeur saisit les informations de carte ou de banque dans le formulaire de REDA Pay. REDA Pay les envoie à Payload par une connexion chiffrée, Payload renvoie un jeton, et REDA Pay conserve le jeton et les informations descriptives listées ci-dessus. Les informations transitent par votre organisation Salesforce en route vers Payload ; elles ne sont écrites ni dans un enregistrement, ni dans un journal, ni dans un fichier.
Ce que cela implique pour vous :
- Considérez votre organisation Salesforce comme faisant partie de l’environnement qui traite des données de carte, et sécurisez-la : authentification forte pour chaque utilisateur, accès selon le moindre privilège, pas de journaux de débogage des écrans de paiement en production.
- Discutez avec Payload et votre évaluateur de ce que cette architecture implique pour votre périmètre PCI DSS et pour le questionnaire que vous remplissez. La conception de REDA Pay garde les données de carte hors de votre base de données ; elle ne vous place pas à elle seule « hors périmètre ».
- Vous pouvez aussi tenir entièrement les payeurs à l’écart de votre personnel grâce aux liens de paiement et au portail, pour que le personnel ne voie ni ne saisisse jamais de numéro de carte.
Sessions, liens et invités
| Mécanisme | Ce qu’il protège |
|---|---|
| Session de paiement chiffrée | Chaque écran de paiement s’exécute à partir d’un jeton chiffré créé à son ouverture, qui indique qui paie, avec quel profil et quel compte. Il expire après la durée de session du compte (15 minutes par défaut) : une adresse copiée ou mise en favori ne peut pas être réutilisée plus tard |
| Identifiant de lien chiffré | Un lien de paiement porte l’identifiant de l’ordre chiffré ; l’adresse ne révèle rien du montant ni du client |
| Accès invité par règle | L’utilisateur invité du site public ne peut lire un Pay Order que tant que Has Active Link est vrai, et un Pay Customer que tant qu’il a un lien actif, grâce aux règles de partage que vous créez. Lorsqu’un lien est payé, expire ou est révoqué, les enregistrements sortent de la vue de l’invité |
| Moyens invité à usage unique | Une carte ou un compte saisi sur un lien est enregistré avec Keep Active décoché |
| Protection contre les doublons | Un second appui sur le bouton de paiement dans une même session est refusé |
| Capture de la géolocalisation et de l’IP | Enregistrement facultatif, et exigence, du lieu d’où un paiement a été effectué ; consultez Contrôles |
Mises à jour de statut provenant de Payload
Payload signale les événements à une adresse publique de votre organisation. Le message sert uniquement à savoir quelle transaction a changé ; REDA Pay lit ensuite la transaction chez Payload via l’API authentifiée et enregistre ce résultat. Rien de ce que contient un message entrant n’est écrit directement dans un enregistrement. Consultez Configurer les webhooks.
Qui peut faire quoi
L’accès est accordé par sept ensembles d’autorisations, de la consultation seule à l’administration, et par deux commutateurs de l’enregistrement utilisateur pour les encaissements et les décaissements ; consultez Qui peut faire quoi. Dans l’organisation, la plupart des objets REDA Pay sont en Public Read Only : tout utilisateur sous licence ayant accès à l’objet peut lire les enregistrements de paiement ; restreignez avec vos propres paramètres de partage si votre politique l’exige. Le suivi de l’historique des champs est activé pour la plupart des champs, ce qui vous donne une piste d’audit des modifications.
Votre liste de contrôle avant la mise en production
| Élément | Pourquoi |
|---|---|
| ERROR_STACK_TRACE à FALSE | Le détail technique ne doit pas atteindre les payeurs ; consultez Paramètres d’organisation |
| Ensembles d’autorisations attribués par rôle, Enable Disbursements uniquement là où il faut | Moindre privilège |
| Ensemble de partage du portail et règles de partage invité exactement comme documenté | Les clients ne voient que leurs propres enregistrements ; les invités, que les liens actifs |
Logo et pied de page servis en https | Pas de contenu mixte sur la page de paiement |
| Authentification multifacteur pour le personnel qui encaisse | Bonne pratique Salesforce |
| Journaux de débogage désactivés pour les utilisateurs de paiement en production | Les journaux peuvent capturer les données des requêtes |
| Un responsable nommé pour la vue Attention Needed des REDA Pay Logs | Les échecs sont vus |
| Clés API Payload enregistrées uniquement via Update API Token, jamais dans des champs, des documents ou des conversations | La clé, c’est le compte |
| Cartes de test et environnement de test de Payload utilisés dans les sandboxes | Jamais de vraies cartes en test |
Questions fréquentes
REDA Pay est une application qui s’exécute dans votre organisation Salesforce ; le processeur de paiement est Payload. Demandez à Payload son attestation et demandez à votre évaluateur comment une intégration qui fait transiter les données de carte par votre organisation affecte votre propre périmètre. Cet article décrit exactement ce que fait l’application, pour que cet échange soit bien informé.
Oui : le propriétaire et le créateur du Pay Order, le Processed User Type et, lorsqu’ils sont capturés, l’IP Address, la Geo Latitude et la Geo Longitude.
Elle ne peut être ni exportée ni régénérée, et elle réside dans votre organisation. Les sandboxes ont la leur ; celle de la production reste avec la production.