Intégrations partenaires

Nex permet à des applications tierces — terminaux de paiement, plateformes e-commerce, agrégateurs — d'encaisser pour le compte de marchands enregistrés sur Nex. Le marchand garde le contrôle total : il accorde, suspend ou retire à tout moment l'autorisation que vous avez de toucher à son compte.

Ce guide s'adresse aux développeurs d'applications partenaires. Si vous êtes l'équipe Nex qui provisionne une nouvelle intégration, voir aussi la procédure interne CMMS (à venir).

Que pouvez-vous faire ?

Capacité	Détail
Créer une commande	Demander à Nex de générer un QR de paiement au nom d'un marchand qui vous a autorisé. Le QR encode un montant verrouillé.
Encaisser via QR	Le client final scanne votre QR avec son appli mobile Nex, paie en quelques secondes, l'argent crédite directement le wallet du marchand.
Recevoir un webhook	Nex vous notifie en temps réel quand un de vos QR a été payé. Vous savez quand débloquer la marchandise, imprimer le ticket, etc.
Gérer les autorisations	Lister vos connexions marchands actives, en révoquer une, faire la rotation de vos clés de sécurité.

Concepts métier

Avant d'attaquer le code, ces 4 termes reviennent partout.

Intégration

Votre identité technique chez Nex. Une seule par application. Provisionnée par l'équipe Nex au démarrage du partenariat. À cette intégration sont attachés :

• Clés API : utilisées pour vous authentifier sur l'API publique. Vous pouvez en avoir plusieurs simultanément (utile pour rouler progressivement sur une nouvelle clé sans casser les terminaux déjà déployés).
• Webhook secret : utilisé pour signer les webhooks que Nex vous envoie. Permet à votre serveur de vérifier qu'un POST entrant vient bien de Nex.
• URL de webhook : endpoint HTTPS où Nex POST les événements.

Connexion intégration ↔ marchand

L'autorisation d'un marchand donné à votre intégration. Vous ne pouvez encaisser pour un marchand que si une connexion active existe entre vous et lui. La connexion porte aussi les scopes accordés (par exemple orders.write pour créer des commandes).

Une connexion suit un cycle de vie : pending (en attente d'accord du marchand) → active (utilisable) → revoked (coupée) ou rejected (le marchand a refusé) ou expired (le marchand n'a pas répondu à temps).

Commande

Une demande de paiement matérialisée par un QR temporaire que vous générez via l'API. Le QR contient un montant verrouillé et expire (5 min par défaut, 15 min max). Une commande = un QR = un paiement attendu.

Webhook

Une notification HTTP POST signée que Nex envoie à votre URL configurée quand un événement vous concerne arrive. Aujourd'hui le seul événement émis est order.paid (un de vos QR a été payé), d'autres viendront.

Architecture en un schéma

Les flèches solides sont des appels HTTP que vous initiez ou recevez. Les flèches pointillées sont des canaux asynchrones (email, webhook).

Plan de la documentation

Page	Contenu
Obtenir vos credentials	Comment l'équipe Nex vous provisionne, et comment tester que ça marche.
Connecter un marchand	Procédure complète : faire la demande, ce que voit le marchand, comment savoir que c'est OK.
Encaisser pour un marchand	Procédure complète : créer un QR, le faire scanner, savoir que c'est payé.
Recevoir les webhooks	Format, garanties, ce qu'il faut faire dans votre receiver.
Guide implémentation receiver	Code complet Express/Fastify : signature, anti-rejeu, idempotence.
Cycle de vie	Rotation de clés, révocation, qui peut faire quoi.
Référence API	Annexe technique : endpoints, headers, codes erreur, catalogue events.

Contact

partners@paywithnex.com — SLA 1 jour ouvré pour les questions d'intégration.