Guide d’intégration PHP

Valider un IBAN dans un formulaire PHP

Créez un petit formulaire côté serveur qui vérifie un IBAN avec IBAN-Test, éloigne votre jeton API du navigateur et informe clairement les clients lorsqu'une vérification ne peut pas être effectuée.

Télécharger le pack de démarrage de formulaires PHP

Ces instructions utilisent PHP version 8.2 ou supérieure avec cURL et sessions. Le téléchargement comprend un formulaire fonctionnel, un client API distinct, des tests hors ligne et des instructions de configuration. Il s’agit d’un exemple pédagogique à exécuter localement : ajoutez une authentification à votre application et une limite de débit partagé avant de publier un point de terminaison qui consomme votre quota d'API.

Télécharger le kit de démarrage (ZIP)

PHP 8.2+ · cURL et sessions · aucune dépendance de Composer

État des tests : Les tests inclus utilisent un transport simulé et des identifiants fictifs pour vérifier les résultats valides, invalides et indisponibles, le rejet CSRF, l’échappement HTML et le délai entre envois. Ils simulent un transfert en échec pour tester les délais d’attente sans attendre le réseau. Il ne s’agit pas d’un test authentifié de l’API réelle. Utilisez ces tests lors de l’adaptation, puis vérifiez votre environnement de préproduction avant d’accepter les envois de vrais clients.

1. Comprendre le flux des demandes

Le navigateur affiche un formulaire HTML standard. Une fois soumis, l'IBAN et un token CSRF sont transférés de la session vers votre application PHP. PHP vérifie le jeton de formulaire, délimite l'entrée et supprime les espaces normaux avant de demander l'API. Le navigateur ne se connecte jamais directement à IBAN-Test et ne reçoit pas le jeton Bearer.

Le backend envoie JSON à POST https://www.iban-test.eu/api/v2/iban/validate. Il lit l'état HTTP et les champs JSON, mappe le résultat à un message utilisateur spécifié et renvoie une autre page HTML. L'interface est décrite dans la documentation de l’API IBAN-Test.

Browser form → your PHP backend → IBAN-Test API
Browser result ← controlled message ← HTTP status and JSON

Conservez cette répartition même avec une personnalisation AJAX : JavaScript est autorisé à appeler votre propre application, mais l'authentification auprès de IBAN-Test reste sur le serveur. Un jeton dans un fichier JavaScript ou un bundle minifié n'est pas secret.

2. Démarrez l'exemple localement

Décompressez le fichier ZIP et accédez au répertoire demo. Vérifiez la version PHP et l'extension cURL à l'aide de php -v et php -m. Les sessions et JSON doivent également être disponibles. Composer n’est pas requis. Tout d’abord, exécutez les vérifications hors ligne incluses :

php tests/run.php

Pour les tests d'API réels, vous aurez besoin d'un jeton de votre compte IBAN-Test. Dans Bash, utilisez une entrée masquée afin que la valeur ne se retrouve pas dans l'historique du shell sous la forme d'une commande en texte brut :

read -r -s -p 'IBAN-Test API token: ' IBAN_TEST_API_TOKEN
printf '\n'
export IBAN_TEST_API_TOKEN
php -d display_errors=0 -d post_max_size=4K -S 127.0.0.1:8080 -t public

Ouvrez http://127.0.0.1:8080. Le serveur écoute uniquement sur votre ordinateur. Arrêtez-le avec Ctrl+C puis exécutez unset IBAN_TEST_API_TOKEN. Le serveur de développement PHP est utilisé pour cet exercice local. Laissez public défini comme racine du document pour conserver le client, les tests et le README en dehors du répertoire fourni.

Sans la variable d'environnement, le formulaire sera toujours chargé. Si l'entrée est plausible, elle affiche alors un message d'indisponibilité sans interroger l'API. Les vraies requêtes API nécessitent un compte actif et consomment un quota.

3. Pré-vérifiez les entrées et protégez le formulaire

L’exemple accepte une chaîne de 80 octets au maximum, supprime les espaces ordinaires, convertit les lettres en majuscules et vérifie un motif simple de caractères. Il rejette ainsi à faible coût les saisies manifestement inadaptées. Ces contrôles ne calculent pas la somme de contrôle et ne confirment pas la validité de l’IBAN ; le serveur a toujours besoin du résultat de l’API.

Un jeton aléatoire stocké dans la session est envoyé sous forme de champ caché et comparé lors de son envoi. Un autre jeton est rejeté avant l'appel d'API. Il y a également une période d'attente de trois secondes entre les inscriptions par session. Cela évite les clics répétés, mais ne constitue pas une limitation des requêtes adaptée à la production car les utilisateurs peuvent créer de nouvelles sessions.

Toutes les valeurs insérées dans HTML sont masquées avec htmlspecialchars, y compris l'entrée réaffichée après une erreur. L'implémentation échappe explicitement aux guillemets et remplace les séquences UTF-8 non valides conformément à Référence de masquage PHP. Les réponses du navigateur utilisent Cache-Control: no-store. Les cookies de session utilisent HttpOnly et SameSite ; Les options sont expliquées dans le Documentation des sessions PHP.

4. Envoyez une demande API limitée

Le client lit IBAN_TEST_API_TOKEN sur le serveur et envoie un en-tête Authorization: Bearer. Le contenu de la demande contient uniquement l'IBAN normalisé :

{"iban":"DE89370400440532013000"}

L'objectif est précisé dans le code. Les soumissions de formulaire ne peuvent pas sélectionner un hôte. Le certificat TLS et le nom d'hôte sont toujours vérifiés ; Les redirections sont désactivées. L'établissement de la connexion est limité à trois secondes et la totalité de la transmission est limitée à huit secondes. Une réponse supérieure à 64 KiB interrompt la transmission. Les options sont décrites par le Référence PHP cURL.

Il n'y a pas de répétition automatique. Après un délai d'attente, il peut être difficile de savoir si le fournisseur a traité la demande ; Les répétitions peuvent consommer un quota supplémentaire. C'est pourquoi la page affiche une erreur temporaire. Si votre application ajoute ultérieurement des tentatives, définissez une stratégie limitée qui prend en compte à la fois la latence et le quota.

5. Afficher le résultat correct

Vérifiez à la fois la transmission réussie et les champs de réponse. Pour ce point de terminaison, l'exemple selon codes de résultat documentés couvre trois cas :

Valide : HTTP 200, la valeur entière code: 2100 et la valeur booléenne error: false doivent être présentes ensemble.
Coordonnées bancaires invalides : Une réponse HTTP 200 correctement construite avec le code 3100, 3101 ou 3102 et la valeur booléenne error: true demande une correction. Les réponses contradictoires avec error: false sont considérées comme indisponibles.
Non disponible : Les problèmes d'authentification ou de quota, les différentes valeurs de statut HTTP, les délais d'attente, les codes inconnus et le mauvais JSON génèrent un message d'erreur technique.

Une vérification indisponible ne doit pas indiquer au client que son IBAN est invalide. L’exemple utilise ses propres messages plutôt que le texte brut du fournisseur. Un résultat valide confirme la validation formelle ; il ne prouve ni la titularité ni l’existence du compte, ni la réussite d’un paiement.

6. Préparez l'application pour l'exploitation

Avant de rendre le formulaire public, exigez une autorisation dans l’application et imposez un budget de quota partagé entre utilisateurs, sessions et instances. Pour les achats sans compte, liez l’accès à une session d’achat autorisée par le serveur et ajoutez une protection contre les abus. Le délai entre envois et le contrôle CSRF ne suffisent pas à protéger votre quota payant.

Utilisez HTTPS, des cookies sécurisés, un serveur PHP de qualité production et des limites de taille du contenu des requêtes côté serveur. Configurez explicitement les proxys de confiance lorsque TLS se termine en amont. Fournir des secrets sur votre environnement d'hébergement ; PHP-FPM peut nécessiter une configuration d'environnement explicite. Excluez les jetons, le contenu des demandes IBAN et les détails sensibles des erreurs des journaux et de la surveillance. Ne publiez jamais une page de diagnostic qui génère les variables d'environnement.