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 comparée en texte brut	Recherche à partir du SHA-256 de la valeur présentée
Une clé révoquée ou expirée cesse immédiatement de fonctionner	`401`, vérifié avant tout autre contrôle
Une clé privée ne peut pas être utilisée depuis un navigateur	Une clé `sk.` accompagnée de `Origin` ou `Referer` est refusée avec `403`
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, quinze 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	Bases de données distinctes, sélectionnées par la clé utilisée pour l'authentification
Une nouvelle tentative ne peut pas débiter deux fois	`Idempotency-Key`, cache de 24 heures et index unique permanent

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, dans la limite d'une alerte par heure. 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. 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. Une seule transaction archive la ligne, puis l'anonymise.

É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, y compris les entrées du coffre-fort
Instantanés des transactions	Pseudonymisés pour conserver l'équilibre comptable
Index de recherche	Client retiré
Piste d'audit	Anonymisation enregistrée

Les identifiants fiscaux constituent la seule exception. Ils sont conservés lorsqu'un dossier de conformité approuvé fait référence au client, car leur suppression empêcherait de respecter une obligation déclarative qui subsiste après la requête.

L'opération est idempotente

Un client dont l'e-mail et le téléphone valent déjà null et dont le nom commence par Deleted User est reconnu comme anonymisé et ignoré. Vous pouvez répéter l'appel sans risque. Il ne crée jamais deux archives.

Les transactions ne sont pas supprimées. Elles conservent le pseudonyme, ce qui rend le payeur non identifiable tout en préservant votre comptabilité.

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

La clé utilisée pour l'authentification sélectionne la base de données avant que la requête n'atteigne un contrôleur. Une clé de la sandbox et une clé du mode live appartenant à la même équipe lisent des tables entièrement différentes.

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

Les six plafonds du compte d'une équipe qui n'a pas validé la conformité sont fixés à zéro. Toute opération est donc refusée. Les paiements live répondent avec 402 et error_code: merchant_not_verified, tandis que les payouts répondent avec 422. La sandbox continue de fonctionner normalement. Plafonds et quotas présente les plafonds et les multiplicateurs qui permettent de les augmenter.

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