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

Garantie	Mécanisme
Une clé n'est jamais conservée ni comparée en texte brut	Les clés sont conservées chiffrées ; réafficher une clé demande un code de vérification de sécurité
Une clé révoquée ou expirée cesse immédiatement de fonctionner	`401`, vérifié à chaque requête
Une clé privée ne peut pas être utilisée depuis un navigateur	Une clé `sk.` détectée dans une requête de navigateur est refusée avec `403` et le propriétaire est alerté
Une clé divulguée peut être limitée à vos serveurs	Liste d'IP autorisées propre à la clé, avec une adresse exacte ou une plage CIDR
Une clé peut être limitée à ses besoins	Clés restreintes, quatorze scopes de ressources, en lecture et en écriture
Un webhook prouve qu'il provient de Wajub	HMAC-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 live	La 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 fois	`Idempotency-Key` : la première réponse est renvoyée pendant 24 heures, et 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.

Une clé utilisée dans un navigateur est signalée, pas seulement refusée

Une clé privée accompagnée d'un en-tête de navigateur est refusée. Son propriétaire reçoit un e-mail. Considérez cet e-mail comme une notification de fuite et renouvelez la clé, car la requête nous est parvenue avec une clé valide.

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

Les numéros de carte n'atteignent jamais Wajub. Le payeur saisit sa carte dans les champs ou la fenêtre du fournisseur de cartes. Wajub ne reçoit que ce que ce fournisseur lui renvoie : un jeton, des champs chiffrés ou une référence de session.

Fournisseur de cartes	Où le payeur saisit sa carte
Stripe	Les champs de carte de Stripe, dans le Checkout hébergé ou Wajub Components
Adyen	Les champs de carte chiffrés d'Adyen, dans le Checkout hébergé ou Wajub Components
Mollie	Les champs de carte de Mollie, dans le Checkout hébergé ou Wajub Components
PayPal	Le bouton et le formulaire carte de PayPal, dans le Checkout hébergé ou Wajub Components
Paystack, Flutterwave, FedaPay, Paddle, PayDunya, CinetPay, Kkiapay	La fenêtre de paiement du fournisseur, ouverte par-dessus le Checkout hébergé ou Wajub Components

Les SDK mobiles utilisent les champs de Stripe quand Stripe traite la carte, sur iOS par le CardCollector que votre application écrit avec le SDK de Stripe. Pour les autres fournisseurs, ils ouvrent la page de paiement du fournisseur. Vos serveurs ne manipulent pas non plus de données de carte : ils créent le paiement et orientent le payeur vers un checkout.

Les données de carte en clair sont refusées

Un numéro de carte, un code de sécurité ou un code PIN de carte envoyé à POST /payments/{id} ou à l'API de session de paiement est refusé avec 422 et error_code: raw_card_data_not_accepted, avant tout traitement. Le sandbox n'accepte que les cartes listées dans Scénarios de test et refuse tout autre numéro avec error_code: sandbox_test_card_required.

Après le débit d'une carte, nous ne conservons que deux fragments.

Fragment	Ce qu'il représente	Utilisation
Huit premiers chiffresHuit premiers chiffres	Le BIN de l'émetteur	Évaluation du risque, informations sur l'émetteur et le pays
Quatre derniers chiffresQuatre derniers chiffres	Affichés sous la forme `**** 4242`	Permettre à un payeur de reconnaître sa carte

Les chiffres intermédiaires ne sont jamais enregistrés. Un moyen de paiement sauvegardé contient un jeton et ces deux fragments, 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 conserve une copie complète dans une archive, puis anonymise la fiche et la supprime. Si une étape échoue, rien ne change et l'appel répond 500.

Élément	Résultat
Fiche du client	`name` devient `Deleted User {pseudonym}` et tous les autres champs d'identification deviennent null
Adresses	Supprimées
Moyens de paiement sauvegardés	Supprimés
Instantanés des transactions	Pseudonymisés pour conserver l'équilibre comptable
Factures	Conservées, toujours liées au client, avec le nom, l'e-mail, le téléphone, l'adresse et le numéro fiscal remplacés par un pseudonyme
Recherche	Le client ne peut plus être trouvé par la recherche, et la recherche sur ses paiements et ses factures ne renvoie plus ses coordonnées
Événements enregistrés	Les coordonnées du client sont retirées des événements déjà enregistrés, y compris les adresses d'un paiement et la copie du client sur une facture : Konsole, `GET /events` et un rejeu montrent la fiche anonymisée
Webhooks livrés	Le corps enregistré pour chaque livraison est nettoyé de la même façon : Konsole le montre nettoyé et une relance l'envoie nettoyé. La copie reçue par une plateforme Sync est nettoyée aussi
Statistiques	Les données du client sont supprimées
Archive	La copie complète est conservée 120 jours, puis supprimée définitivement
Piste d'audit	Anonymisation enregistré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 et ne crée jamais deux archives. Il termine ce qu'un appel précédent a laissé : un client supprimé mais jamais anonymisé est anonymisé, et le nettoyage des événements et des livraisons est relancé au cas où il aurait échoué.

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. Leur instantané du client est pseudonymisé et leur lien avec le client est retiré, 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 : les rails Wajub ou votre propre connexion Stripe, Paystack ou autre. 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.

Pages associées