Toutes les routes de ce groupe nécessitent le header Authorization: Bearer sk_... et un scope de clé API PAYIN ou BOTH à la création.
Vue d’ensemble
Un lien de paiement est réutilisable — contrairement à une session de checkout, qui est à usage unique, un même lien peut générer un nombre illimité (ou limité via usage_limit) de Transaction au fil du temps :
Montant fixe ou libre
Aucune validation croisée n’est appliquée côté serveur entre amount_type et amount : rien n’empêche de créer un lien amount_type: "FIXED" sans amount renseigné. Vérifiez la cohérence de ces deux champs côté intégrateur avant de créer le lien.
merchant non réassignable
Le champ merchant est résolu à la création (votre clé API elle-même, ou le marchand actif du dashboard) et reste en lecture seule pour toute mise à jour ultérieure — un PATCH/PUT ne peut jamais réattribuer un lien existant à un autre marchand.
Retrouver les paiements d’un lien
GET /payment-links/{id}/transactions/ retourne les Transaction générées par ce lien précis.
Cette vue n’accepte aucun filtre ni recherche — contrairement à GET /transactions/, qui supporte status, currency, plages de dates, etc. Seul le lien lui-même filtre le résultat. Elle utilise aussi une pagination par numéro de page classique (count/next/previous), pas la pagination par curseur de /transactions/ — une incohérence entre les deux endpoints à garder en tête si vous consommez les deux. POST /payment-links/ n’exige pas de header Idempotency-Key (dette technique connue) — un double-clic ou un retry réseau non protégé peut créer deux liens de paiement distincts.
