Aller au contenu

Paiements

À quoi ça sert

Cet écran permet à l'équipe Jigi de traiter la file des paiements de tenants qui nécessitent une intervention manuelle — validation, rejet ou demande d'information complémentaire — avant que l'abonnement du client ne soit confirmé.

Prérequis

Prérequis

  • Modules sous licence : PLATFORM (espace opérateur Jigi)
  • Permissions : platform.payments.manage
  • Rôles : JIGI_OPERATOR, JIGI_ADMIN

Comment ça marche

Traiter la file des paiements en attente

  1. Ouvrir Finance → Paiements en attente (/admin-jigi/payments/pending).
  2. La liste peut être filtrée par méthode de paiement et est paginée.
  3. Pour chaque paiement en attente, trois actions individuelles sont disponibles :
  4. Valider — confirme le paiement et débloque l'abonnement correspondant côté tenant.
  5. Rejeter — refuse le paiement (avec un motif à saisir) ; l'abonnement du tenant reste bloqué ou repasse à un statut antérieur.
  6. Demander des informations — envoie une demande de complément au client (avec un motif/message à saisir) sans trancher immédiatement.
  7. Une validation par lot est disponible pour traiter plusieurs paiements identiques en une seule action lorsqu'un opérateur a plusieurs dossiers similaires à valider d'un coup (par exemple après vérification manuelle d'un lot de virements reçus).
  8. Cliquer sur un paiement ouvre son détail complet pour vérifier les informations avant de trancher (montant, méthode, tenant concerné).

Pourquoi un paiement finit-il dans cette file ?

Les paiements qui transitent par une méthode nécessitant une vérification humaine (par exemple un virement bancaire) — plutôt qu'un paiement carte automatiquement confirmé par le fournisseur de paiement — atterrissent dans cette file en attente de traitement manuel par un opérateur.

Qui peut faire quoi

Permission requise Rôles concernés
platform.payments.manage JIGI_OPERATOR, JIGI_ADMIN
Action JIGI_OPERATOR JIGI_ADMIN
Lister/consulter les paiements en attente ✅ ✅
Valider, rejeter, demander des informations, valider par lot (platform.payments.manage) ✅ ✅

Cette permission a été attribuée aux deux rôles dès la migration fondatrice V121__jigi_operator_platform.sql — aucune nuance particulière entre JIGI_OPERATOR et JIGI_ADMIN sur ce module.

Détails techniques

Détails techniques
  • Endpoints (PaymentAdminController, base /admin-jigi/payments), tous protégés par platform.payments.manage :
    • GET /pending (avec filtre method et pagination)
    • GET /{paymentId} — détail
    • POST /{paymentId}/validate
    • POST /{paymentId}/reject (corps PaymentActionRequest, motif requis)
    • POST /{paymentId}/request-info (corps PaymentActionRequest)
    • POST /batch-validate (corps BatchValidationRequest, retourne le nombre validé)
  • Table d'audit dédiée : subscription.payment_audit_log (entité PaymentAuditLog : paymentId, action, operatorId, reason, createdAt) — distincte du journal d'audit opérateur général, spécifique aux décisions de paiement.
  • Frontend : frontend/src/app/admin-jigi/payments/pending/page.tsx.

Cas d'erreur et FAQ

Un client dit avoir payé mais son abonnement n'est pas actif, que vérifier ? Ouvrez la file /admin-jigi/payments/pending et cherchez son paiement (filtrez par méthode si besoin). S'il y figure, vérifiez le détail puis validez-le si les informations sont correctes.

Pourquoi rejeter un paiement plutôt que simplement l'ignorer ? Le rejet trace explicitement la décision avec un motif dans subscription.payment_audit_log, ce qui est nécessaire pour la traçabilité et pour informer correctement le client du refus.

À quoi sert « Demander des informations » plutôt que rejeter directement ? Cela permet de ne pas trancher immédiatement quand un justificatif ou une précision manque, sans bloquer définitivement le dossier par un rejet.

Quand utiliser la validation par lot ? Lorsque plusieurs paiements de même nature (par exemple un lot de virements reçus le même jour) ont déjà été vérifiés individuellement en amont et peuvent être confirmés ensemble.

Existe-t-il une limite au nombre de paiements traités par lot ? Le comportement exact dépend du corps de la requête envoyée (BatchValidationRequest) ; en cas de doute sur un très gros lot, préférez plusieurs validations manuelles pour garder une trace individuelle plus lisible.

Voir aussi