value: req.body.total dans une commande PayPal permet à un acheteur de payer 0.01 pour n'importe quoi, et une route de webhook qui marque les commandes comme payées sans appeler verify-webhook-signature permet à n'importe qui d'envoyer un faux PAYMENT.CAPTURE.COMPLETED. Ce skill détecte ces erreurs et dix autres erreurs d'intégration PayPal avant que vous n'encaissiez de vrais paiements, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur votre code serveur (JavaScript et TypeScript, Python, PHP, Ruby, Java, C#, Go), vos pages et composants (templates HTML, JSX/TSX, Vue, Svelte), vos fichiers .env, la configuration de l'application et les manifestes de dépendances qui mentionnent PayPal, des types d'événements de webhook PayPal ou des champs IPN. Il suit les valeurs de la requête à travers les affectations, la déstructuration, les wrappers simples et les paramètres des fonctions utilitaires : un prix recherché côté serveur à partir d'un ID envoyé par le client n'est donc pas signalé, la dernière affectation avant une utilisation l'emporte, et un montant de don vérifié par rapport à vos valeurs prédéfinies ou à vos limites est accepté. Il évalue chaque route de webhook séparément (middleware, guards et appels de vérification comptent), distingue le code navigateur du code serveur et examine l'ensemble du projet avant de considérer une capture côté navigateur comme fiable. Il connaît les modèles du PayPal Server SDK, le corps REST d'Orders v2, les helpers actions du JavaScript SDK et checkout.js. Il n'exécute jamais votre code et n'appelle jamais PayPal. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en ligne)

• P01 : le secret client dans une variable d'environnement publique (NEXT_PUBLIC_, VITE_, REACT_APP_ et similaires), un bloc env de Next.js, un define du bundler, la configuration runtime publique de Nuxt ou du code navigateur, ou une demande de jeton OAuth depuis le navigateur
• P02 : secrets client PayPal, mots de passe ou signatures de l'API NVP/SOAP, jetons d'accès, identifiants Basic ou jetons de production Braintree écrits dans le code ou dans une configuration commitée, y compris les valeurs de repli littérales et .env.example
• P03 : montant, devise ou purchase units de la commande repris de la requête sans contrôle par liste autorisée ou par limite, additionnés à partir de prix envoyés par le client, ou corps de requête entier transmis à PayPal
• P04 : actions.order.capture() dans le navigateur dont le résultat est envoyé à votre serveur ou à une page de confirmation, sans code serveur qui interroge PayPal sur la commande ou vérifie un webhook
• P05 : routes de webhook sans vérification de signature (Express, Next.js, NestJS, Flask, Django, Laravel, Rails, Go) et listeners IPN sans postback cmd=_notify-validate

REVIEW (à vérifier avant la publication)

• P11 : hôtes sandbox ou mode sandbox dans la configuration de production, ou mode live pointant vers un hôte sandbox
• P12 : SDK PayPal obsolètes ou abandonnés (paypal-rest-sdk, @paypal/checkout-server-sdk, paypalrestsdk, les anciens SDK PHP, Ruby, .NET et Java, checkout.js)
• P13 : captures côté serveur qui marquent les commandes comme payées ou livrent sans vérifier COMPLETED
• P14 : commandes créées dans le navigateur avec actions.order.create()
• P15 : listeners IPN qui omettent les vérifications de payment_status, receiver et mc_gross
• P16 : vérification des certificats TLS désactivée dans du code qui communique avec PayPal
• P17 : journalisation du PayPal Server SDK avec des en-têtes sensibles non masqués, ce qui écrit le jeton d'accès dans les logs

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec, pour chaque règle, la raison, l'approche plus sûre et le lien vers la documentation officielle de PayPal
• Un projet d'exemple risqué et un projet sûr, ainsi que le vrai rapport produit par le scanner sur le projet risqué

Limites

Il lit chaque fichier tel qu'il est écrit. Les valeurs transmises via d'autres modules, des bases de données ou les mécanismes internes d'un framework ne sont pas suivies, les valeurs de requête en Java, C# et Go ne sont suivies qu'à travers les paramètres @RequestBody et [FromBody], et les réglages du tableau de bord (abonnements aux webhooks, identifiants live, préférences de réception des paiements) ne sont pas visibles. P04 ne voit que les fichiers que vous analysez : analysez donc l'ensemble du projet. Le stockage sécurisé des moyens de paiement (vaulting), les versements et la logique d'abonnement ne sont pas vérifiés au-delà des règles ci-dessus. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP de 22 fichiers : SKILL.md, le scanner dans scripts/ (7 fichiers Python), references/rules.md (chaque règle avec sa raison et l'approche plus sûre) et examples/ (12 fichiers d'exemple plus report.md, la vraie sortie du scanner sur l'exemple risqué).

Utilisation : il s'agit d'un skill d'agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier de skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.