> ## Documentation Index
> Fetch the complete documentation index at: https://docs.i-pay.money/llms.txt
> Use this file to discover all available pages before exploring further.

# Liens de paiement

> Créer un lien de paiement hébergé et consulter son état.

Un lien de paiement délègue l'interface de paiement à iMoney Encaissement : plutôt que de construire votre propre formulaire, vous redirigez votre client vers une page de paiement hébergée, où il choisit son [moyen de paiement](/guides/reversement#frais-par-moyen-de-paiement) et valide. La réponse de création renvoie `page_url`, qui est cette page : transmettez-la à votre client (redirection, email, SMS, réseau social). Ne considérez jamais la redirection du client comme une confirmation de paiement : vérifiez l'état du lien côté serveur, avec la consultation ci-dessous ou avec un [webhook](/guides/webhooks), avant de livrer une commande.

## Créer un lien de paiement hébergé

Cette opération crée une page de paiement hébergée par iMoney Encaissement : vous obtenez une URL à
partager plutôt qu'une intégration à construire côté client. C'est l'équivalent API du lien créé
depuis le tableau de bord.

### En-têtes et environnements

L'authentification, les clés et le choix Sandbox ou Live suivent les mêmes règles que le reste de
l'API : voir [Authentification](/api-reference/authentification).

### Paramètres

Si vous fournissez vous-même `reference` plutôt que de laisser l'API la générer, gardez à l'esprit
qu'elle devient l'identifiant utilisé pour consulter l'état du lien via
[Consulter un lien de paiement](#get-external-payments-reference) — une opération non
authentifiée. Générez donc une valeur aléatoire à forte entropie, jamais un identifiant de
commande séquentiel ou prévisible ; laisser l'API générer la référence évite ce risque.

Les deux URL de redirection doivent être en HTTPS : une URL de redirection en HTTP est rejetée.

**Un lien créé par l'API expire toujours, trente minutes après sa création.** La v1 crée un lien
expirant quelle que soit la valeur envoyée dans `shouldExpire`. Transmettez donc le lien à votre
client tout de suite après l'avoir créé, et recréez-en un plutôt que de rediffuser un lien ancien.

### Exemple de requête

Les valeurs du corps d'exemple sont celles du contrat OpenAPI : remplacez-les par vos propres
valeurs avant de l'exécuter.

### Réponse et champs

Conservez `page_url` : c'est la page à transmettre au payeur. `reference` est à conserver de la
même façon que pour un paiement classique, pour un suivi ultérieur.

### Erreurs et limites

Une seconde création avec la même `reference` fournie manuellement échoue en validation (`422`) :
la référence doit rester unique sur votre compte. Il n'existe pas de clé d'idempotence sur cette
opération ; aucune garantie n'est documentée en cas d'appels concurrents avec la même `reference`
(à confirmer auprès du support). Un compte introuvable ou inactif pour l'environnement ciblé
renvoie `404`. La liste des messages d'erreur communs (en-têtes, authentification) est dans
[Erreurs](/api-reference/erreurs).

## Consulter un lien de paiement

**Cette opération ne demande aucune clé.** Toute personne qui connaît la référence peut consulter
l'état du lien et, une fois un paiement complété, les informations du payeur qu'il contient.
Générez toujours cette référence de façon aléatoire et à forte entropie plutôt qu'un identifiant de
commande séquentiel ou devinable — voir [Créer un lien de paiement hébergé](#post-external-payments) pour la
contrainte sur la valeur. Ne journalisez ni n'affichez cette référence dans un contexte accessible
à un tiers non concerné par ce paiement.

### En-têtes et environnements

Aucune clé ni aucun en-tête d'authentification n'est requis pour cette opération.

### Paramètres

Le paramètre de chemin `reference` est la référence du lien : utilisez une référence privée à forte
entropie, non publiée côté client.

### Exemple de requête

Remplacez la référence d'exemple par celle de votre lien.

### Réponse et champs

La forme de la réponse dépend de l'état réel du lien : un paiement mené à son terme, un lien encore
en attente d'un premier essai de paiement, ou un lien expiré sans paiement complété. Un
remboursement effectué après coup ne modifie pas cette forme rétroactivement : cette opération
n'est pas un indicateur fiable pour détecter un remboursement, seul un paiement mené à son terme
change la réponse.

Passé le délai d'expiration de trente minutes sans paiement complété, la consultation répond
toujours `200`, mais avec la forme « lien expiré » : `has_expire` à `true` et `status` à
`cancelled`. Traitez donc cette forme comme un lien définitivement inutilisable — et non comme une
erreur transitoire à retenter.

### Erreurs et limites

Une référence qui ne correspond à aucun lien existant renvoie `404`. Comme cette opération est
publique, une énumération de références par force brute est théoriquement possible si la référence
n'est pas assez aléatoire — c'est la raison de l'avertissement ci-dessus, pas une limite de débit
documentée par ailleurs. Messages d'erreur communs :
[Erreurs](/api-reference/erreurs).