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é secrète ne se relit pas librement | La 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 fonctionner | 401, vérifié à chaque requête |
| Une clé privée ne peut pas être utilisée depuis un navigateur | Une 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 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 : 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 utilisée depuis un navigateur est refusée avec 403, et 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 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.
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} 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.
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ées | Résultat |
|---|---|
| Coordonnées du client | Effacées : nom, coordonnées, adresses et moyens de paiement sauvegardés |
| Transactions et factures | Conservées pour votre comptabilité, avec les coordonnées du client remplacées par un pseudonyme |
| Événements enregistrés et webhooks livrés | Konsole, 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.
Pages associées
- Bonnes pratiques de sécuritéLa protection des clés, leur renouvellement et les actions à effectuer après une fuite.
- Plafonds et quotasLes plafonds débloqués par la vérification.
- AuthentificationLes types de clés, les scopes et les erreurs renvoyées par chaque contrôle.
- Vérification de signatureVérifiez qu'un webhook provient bien de Wajub.