Créer un formulaire de paiement conforme aux bonnes pratiques

Les formulaires de paiement sont l'élément le plus important du processus de paiement. Une mauvaise conception du formulaire de paiement est une cause fréquente d'abandon de panier.

Créez un formulaire qui permet aux utilisateurs de saisir leurs informations de paiement aussi facilement que possible sur ordinateur et mobile. Assurez-vous que le formulaire exploite au mieux les fonctionnalités intégrées du navigateur pour la saisie automatique, la validation et les contraintes de saisie de données.

Mise en œuvre

Vous trouverez ci-dessous les consignes les plus importantes pour créer des formulaires de paiement efficaces.

Utiliser un code HTML pertinent et valide

Tirez le meilleur parti des éléments et des attributs conçus pour créer des formulaires :

  • <form>, <input>, <label> et <button>
  • type, autocomplete et inputmode

Ils activent les fonctionnalités intégrées du navigateur, améliorent l'accessibilité et ajoutent du sens au balisage.

Utilisez l'élément <label> pour ajouter des libellés aux champs de formulaire pour la saisie de données.

Pour ajouter un libellé à un <input>, un <select> ou un <textarea>, utilisez un <label>. Associez un libellé à une entrée en attribuant à l'attribut for du libellé la même valeur que l'attribut id de l'entrée.

Exploiter tout le potentiel des attributs HTML

Facilitez la saisie des données par les utilisateurs en utilisant l'attribut d'élément <input> <type> approprié pour fournir le bon clavier sur mobile et activer la validation intégrée de base par le navigateur.

Utilisez toujours type="email" pour les adresses e-mail et type="tel" pour les numéros de téléphone.

<!-- type="email"/"tel" gives mobile users the right keyboard and enables built-in validation -->
<input type="email" id="email" name="email" autocomplete="email" required>
<input type="tel" id="phone" name="phone" autocomplete="tel">

Chaque élément <input>, <select> et <textarea> DOIT comporter un attribut autocomplete approprié pour améliorer l'accessibilité et éviter aux utilisateurs de saisir à nouveau des données.

Rendre les boutons utiles

Utilisez <button> pour les boutons. Vous pouvez également utiliser <input type="submit">, mais n'utilisez pas d'élément div ou d'autre élément aléatoire agissant comme un bouton. Les éléments de bouton offrent un comportement accessible, une fonctionnalité d'envoi de formulaire intégrée et peuvent être facilement stylisés.

Attribuez à chaque bouton d'envoi de formulaire une valeur qui indique son action. Pour chaque étape du processus de paiement, utilisez un incitation à l'action descriptive qui indique la progression et rend l'étape suivante évidente. Par exemple, nommez le bouton d'envoi de votre formulaire d'adresse de livraison Passer au paiement plutôt que Continuer ou Enregistrer.

Utilisez un seul champ de saisie pour le nom, si possible

Permettez à vos utilisateurs de saisir leur nom dans un seul champ, sauf si vous avez une bonne raison de stocker séparément les prénoms, les noms de famille, les titres honorifiques ou d'autres parties du nom. L'utilisation d'un seul champ de saisie pour le nom simplifie les formulaires, permet le copier-coller et facilite la saisie automatique.

Autoriser les noms internationaux. Pour la validation, évitez d'utiliser des expressions régulières qui ne correspondent qu'aux caractères latins. "Latin uniquement" exclut les utilisateurs dont le nom ou l'adresse incluent des caractères qui ne figurent pas dans l'alphabet latin. Autorisez plutôt la correspondance des lettres Unicode et assurez-vous que votre backend accepte Unicode de manière sécurisée, à la fois en entrée et en sortie. Unicode dans les expressions régulières est bien pris en charge par les navigateurs récents.

Autoriser différents formats d'adresse

Lorsque vous ajoutez des champs de formulaire pour une adresse dans un formulaire de paiement, tenez compte de la variété des formats d'adresse, même au sein d'un même pays. Ne faites pas de suppositions sur les adresses "normales".

Si vos exigences en matière de données le permettent, envisagez d'utiliser un seul élément <textarea> pour l'adresse. Il s'agit de l'option la plus flexible pour différents formats d'adresses locales et internationales.

Utiliser la saisie semi-automatique pour l'adresse de facturation

Par défaut, l'adresse de facturation est identique à l'adresse de livraison. Réduisez l'encombrement visuel en fournissant un lien pour modifier l'adresse de facturation (ou utilisez des éléments de résumé et de détails) plutôt qu'en affichant l'adresse de facturation dans un formulaire.

Utilisez des valeurs de saisie semi-automatique appropriées pour l'adresse de facturation, comme vous le faites pour l'adresse de livraison, afin que l'utilisateur n'ait pas à saisir les données plusieurs fois. Ajoutez un préfixe aux attributs de saisie semi-automatique si vous avez des valeurs différentes pour des entrées portant le même nom dans différentes sections. Exemple :

<!-- Prefix with shipping or billing; note that the valid token is address-line1 (no hyphen before the digit) -->
<input autocomplete="shipping address-line1" ...>
...
<input autocomplete="billing address-line1" ...>

Afficher la progression du paiement

Pour chaque étape du paiement, utilisez des titres de page et des valeurs de bouton descriptives qui indiquent clairement ce qu'il faut faire maintenant et quelle est l'étape suivante.

Utilisez l'attribut enterkeyhint sur les entrées de formulaire pour définir le libellé de la touche Entrée du clavier mobile. Par exemple, utilisez enterkeyhint="previous" et enterkeyhint="next" dans un formulaire multipage, enterkeyhint="done" pour la saisie finale dans le formulaire et enterkeyhint="search" pour une saisie de recherche.

Aidez les utilisateurs à éviter de saisir à nouveau leurs données de paiement

Veillez à ajouter les valeurs autocomplete appropriées dans les formulaires de carte de paiement. Sans la saisie semi-automatique, les utilisateurs peuvent conserver une trace physique des informations de leur carte de paiement ou les stocker de manière non sécurisée.

<!-- cc-number tells autofill this is a card number, not a generic number field -->
<!-- inputmode="numeric" gives a numeric keyboard without the increment/decrement spinner -->
<!-- DO NOT use type="number" — it adds increment/decrement controls and strips leading zeros -->
<input id="cc-number" name="cc-number" type="text" autocomplete="cc-number"
       inputmode="numeric" maxlength="19" pattern="[\d ]{13,19}" required>

<!-- cc-name autofills with the name exactly as it appears on the card; Unicode pattern allows international names -->
<input id="cc-name" name="cc-name" type="text" autocomplete="cc-name"
       maxlength="50" pattern="[\p{L} \-\.]+" required>

<!-- cc-exp autofills the full expiry date as MM/YY -->
<!-- MANDATORY: Place format hints above the input so autocomplete popovers or virtual keyboards do not obscure them during editing -->
<span id="exp-hint" class="hint">Format: MM/YY</span>
<input id="cc-exp" name="cc-exp" type="text" autocomplete="cc-exp"
       aria-describedby="exp-hint" maxlength="5" required>

<!-- cc-csc autofills the security code; DO NOT use type="password" here -->
<input id="cc-csc" name="cc-csc" type="text" autocomplete="cc-csc"
       inputmode="numeric" maxlength="4" pattern="[0-9]{3,4}" required>

Afficher les indications de format au-dessus de la saisie

Lorsqu'un champ requiert un format spécifique (par exemple, la date d'expiration d'une MM/YY), placez l'indice dans un élément visible au-dessus de la saisie et associez les deux avec aria-describedby, comme dans l'exemple cc-exp ci-dessus. Les conseils situés sous un champ de saisie sont facilement masqués par le clavier mobile ou par la fenêtre pop-up de saisie automatique au moment où l'utilisateur en a besoin.

Ne vous fiez pas à l'attribut placeholder comme seul indice de format, et ne l'utilisez jamais à la place d'un <label> : le texte d'espace réservé est masqué dès que l'utilisateur commence à taper, il ne peut donc pas être vérifié lors de la modification. Un espace réservé peut être utilisé comme indice supplémentaire, en plus du libellé et de l'indice persistant.

Ne pas masquer le code de sécurité

Utilisez type="text" avec inputmode="numeric" pour le code de sécurité de la carte, et non type="password". Les utilisateurs ne peuvent pas vérifier si un code masqué à trois ou quatre chiffres comporte des fautes de frappe. Par conséquent, un chiffre mal saisi n'est détecté que lorsque le paiement est refusé. De plus, le masquage n'offre que peu de protection, car le code est imprimé sur la carte que l'utilisateur tient.

Utiliser une seule entrée pour les cartes de paiement et les numéros de téléphone

Pour les numéros de carte de paiement et de téléphone, utilisez un seul champ de saisie : ne divisez pas le numéro en plusieurs parties. Cela facilite la saisie des données par les utilisateurs, simplifie la validation et permet aux navigateurs de remplir automatiquement les champs. Envisagez de faire de même pour d'autres données numériques, telles que les codes PIN et les codes bancaires.

Valider soigneusement

Vous devez valider la saisie des données en temps réel et avant l'envoi du formulaire. Pour ce faire, vous pouvez ajouter un attribut de modèle à une entrée de carte de paiement. Si l'utilisateur tente d'envoyer le formulaire de paiement avec une valeur non valide, le navigateur affiche un message d'avertissement et met l'accent sur l'entrée.

Toutefois, l'expression régulière de votre modèle doit être suffisamment flexible pour gérer les différentes longueurs de numéros de carte de paiement : de 14 chiffres (ou éventuellement moins) à 20 (ou plus). Les codes de sécurité des cartes (également appelés CSC, CVC, CVV ou autres) sont composés de trois ou quatre chiffres.

Autorisez les utilisateurs à inclure des espaces lorsqu'ils saisissent un nouveau numéro de carte de paiement, car c'est ainsi que les numéros sont affichés sur les cartes physiques. Cette approche est plus conviviale pour l'utilisateur (vous n'aurez pas à lui dire qu'il a fait une erreur), moins susceptible d'interrompre le flux de conversion et il est facile de supprimer les espaces dans les nombres avant le traitement.

Aidez les utilisateurs à ne pas oublier de champs de données par accident

Ajoutez l'attribut required aux champs obligatoires. Les navigateurs récents affichent automatiquement une invite et mettent en évidence les données manquantes.

Stratégies de remplacement

La saisie automatique est une amélioration progressive. Dans les navigateurs qui ne sont pas compatibles avec la saisie automatique, les utilisateurs devront simplement saisir manuellement leurs informations de paiement. Les contraintes HTML sémantiques (telles que type, inputmode, pattern et required) continueront de fonctionner correctement pour valider les entrées utilisateur et fournir les claviers virtuels appropriés.