Aller au contenu

Conformité et sécurité

Les règles appliquées par la plateforme et les éléments qui nécessitent un contrat.

Deux questions souvent posées ensemble appellent des réponses très différentes. Cette page décrit les contrôles exécutés par la plateforme sur chaque requête. Vous pouvez les vérifier avec l'API que vous utilisez déjà. Les certifications, les licences et la résidence des données relèvent du contrat. Elles varient selon le marché et le contrat. Pour les obtenir, contactez enterprise@wajub.com plutôt que de consulter une page de documentation.

Contrôles exécutés sur chaque requête

GarantieMécanisme
Une clé secrète ne se relit pas librementLa réafficher dans le Dashboard demande un code de vérification de sécurité
Une clé révoquée ou expirée cesse immédiatement de fonctionner401, vérifié à chaque requête
Une clé privée ne peut pas être utilisée depuis un navigateurUne clé privée utilisée depuis un navigateur est refusée avec 403, et son propriétaire reçoit un e-mail
Une clé divulguée peut être limitée à vos serveursListe d'IP autorisées propre à la clé, avec une adresse exacte ou une plage CIDR
Une clé peut être limitée à ses besoinsClés restreintes, quatorze scopes de ressources, en lecture et en écriture
Un webhook prouve qu'il provient de WajubHMAC-SHA256 calculé sur l'horodatage et le corps, avec une tolérance de 300 secondes
La sandbox ne peut pas accéder aux données du mode liveLa sandbox et le mode live ne partagent aucune donnée ; la clé utilisée pour l'authentification détermine l'environnement
Une nouvelle tentative ne peut pas débiter deux foisIdempotency-Key : un paiement, un transfert ou un remboursement n'est jamais créé deux fois pour une même clé

Bonnes pratiques de sécurité présente chaque contrôle du point de vue de l'intégrateur, y compris le renouvellement sans interruption.

Données de carte et périmètre PCI

Les numéros de carte n'atteignent jamais Wajub ni vos serveurs. Le payeur saisit sa carte dans les champs sécurisés ou la page de paiement du fournisseur de cartes, dans le Checkout hébergé, Wajub Components ou les SDK mobiles, et Wajub ne reçoit que ce que ce fournisseur lui renvoie, par exemple un jeton. Vos serveurs créent seulement le paiement et orientent le payeur vers un checkout.

Wajub ne conserve jamais de numéro de carte complet. Un moyen de paiement sauvegardé est un jeton, jamais un numéro utilisable pour débiter la carte ailleurs.

Supprimer un payeur

DELETE /customers/{id} effectue une véritable suppression, pas un changement de statut. L'appel anonymise la fiche et la supprime.

DonnéesRésultat
Coordonnées du clientEffacées : nom, coordonnées, adresses et moyens de paiement sauvegardés
Transactions et facturesConservées pour votre comptabilité, avec les coordonnées du client remplacées par un pseudonyme
Événements enregistrés et webhooks livrésKonsole, GET /events, un rejeu et un webhook renvoyé montrent la fiche anonymisée

Les identifiants fiscaux constituent la seule exception. Ils sont conservés lorsque l'un d'eux a été vérifié, car un identifiant fiscal vérifié est une preuve d'identité dont l'obligation de conservation subsiste après la requête.

L'opération est idempotente

Répéter l'appel sur un client déjà effacé répond le même 200.

Ce qui a déjà quitté Wajub ne peut pas être rappelé : un webhook reçu par votre endpoint, ou un contenu qu'une plateforme connectée a conservé chez elle, est à vous ou à elle d'effacer. Avec X-Sync, l'appel est refusé avec 403 : effacer un client est une décision du marchand, pas d'une plateforme.

Les transactions ne sont pas supprimées, ce qui préserve votre comptabilité. Le numéro de portefeuille ou de compte avec lequel un paiement a été réglé reste sur ce paiement : il fait partie de l'écriture financière à conserver.

La sandbox et le mode live sont des systèmes distincts

La clé utilisée pour l'authentification détermine l'environnement. La sandbox et le mode live ne partagent aucune donnée, même pour des clés de la même équipe.

Cette séparation produit une réponse 404, pas une erreur d'autorisation. L'identifiant d'un paiement live recherché avec une clé de test n'existe pas, et l'inverse est également vrai. Aucun élément ne passe d'un environnement à l'autre : ni les clients, ni les endpoints de webhook, ni les événements.

La vérification contrôle l'accès aux fonds live

Une équipe qui n'a pas validé la conformité n'encaisse aucun paiement live, quel que soit le fournisseur qui le porterait, y compris vos propres fournisseurs connectés. Chaque paiement live répond avec 402 et error_code: merchant_not_verified jusqu'à l'approbation de la vérification ; la tentative qui suit l'approbation passe. D'ici là, les payouts répondent avec 422. La sandbox continue de fonctionner normalement. Plafonds et quotas présente les plafonds du compte que la vérification débloque.

Signaler une vulnérabilité

Envoyez votre signalement à security@wajub.com. L'API, Konsole, les SDKs et ce site de documentation sont tous concernés. Il n'existe aucun programme public de récompense. Le journal des modifications crédite les divulgations lorsque leur auteur souhaite être nommé.

Questionnaires, certifications et résidence

Toute question relevant d'un contrat reçoit une réponse humaine, pas celle de cette page : statut et certificats de conformité, rapports de tests d'intrusion, accords de traitement des données, engagements de résidence, licences propres à chaque marché et partenaires réglementés de chaque corridor.

Envoyez le questionnaire à remplir à enterprise@wajub.com.

Que pensez-vous de ce contenu ?