Facturation, organisations et remboursements
Paramètres de facturation
Modèle
- Une passerelle active pour l’ensemble de la plateforme (pas de panier multi-fournisseurs).
- Identifiants et conducteur actif : Admin → Paramètres → Paiements.
- Webhooks : POST /webhooks/{driver} (exempté de CSRF).
Fournisseurs disponibles
| Driver | Implemented | Best for |
|---|---|---|
| stripe | Yes | Global cards, Checkout, mature subscriptions |
| paddle | Yes | Merchant of Record, tax-heavy SaaS |
| mollie | Yes | European methods + recurring mandates |
| airwallex | No (credentials UI only) | Future multi-currency; not selectable yet |
| fake | Tests only | PHPUnit; blocked by launch-check in production |
Liste de contrôle de l’opérateur
- Choisissez la passerelle de paiement active.
- Collez les clés API + le secret de webhook pour ce fournisseur.
- Enregistrez l’URL du webhook de production sur le tableau de bord du fournisseur.
- Effectuez un test de paiement avec des clés de test avant de passer en production.
- Ne laissez jamais « Fake » en solution de repli silencieuse — les erreurs de configuration doivent échouer bruyamment.
Modèle d’abonnement (résumé)
- Un abonnement par installation (pas par organisation).
- Les modules complémentaires sont rattachés à cet abonnement / droit d’accès à l’installation.
- L’objet client du fournisseur correspond au profil de facturation de l’organisation.
- Annulation du renouvellement : utilisable jusqu’à la fin de la période, puis suppression différée (règles métier).
- Échec de paiement : relance → bannière de grâce → suspension → suppression logicielle → suppression définitive après le nombre de jours de conservation.
Grâce et conservation : Administrateur → Paramètres → Facturation
Tâche planifiée : billing:process-lifecycle (composeur de planification).
Remboursements
Flux client
- Depuis l’onglet Facturation de l’installation, un membre d’une organisation autorisée soumet une demande de remboursement (référence de facture facultative).
- Une seule demande en attente à la fois par installation (appliqué dans le service).
- Le client est informé de l’approbation ou du rejet par e-mail lorsque le serveur SMTP fonctionne.
Flux d’administration
- Admin → Remboursements liste les demandes en attente.
- Approuver ou rejeter.
Espace réservé de capture d’écran : liste des demandes de remboursement de l’administrateur avec options Approuver / Rejeter
Que se passe-t-il lors de l’approbation ?
Séquence approximative (BillingService::approveRefund + passerelle) :
- Appeler le fournisseur de paiement refundLatestPayment (intégral ou partiel selon l’implémentation).
- Annuler l’abonnement au fournisseur.
- Marquez l’installation pour une terminaison immédiate / suppression logicielle.
- Définissez hard_delete_after en utilisant refund_hard_delete_days (par défaut 7 jours, et non la fenêtre normale de suppression différée de 30 jours).
- Désactivez l’accès au bord afin que la boutique soit hors ligne.
- Notifier le client.
- Lorsque hard_delete_after expire, le job de cycle de vie supprime définitivement : purge des sauvegardes, destruction des ressources hôtes, suppression des données du tenant telles que mises en œuvre.
Effets secondaires (messages de l’opérateur)
| Topic | Effect |
|---|---|
| Money | Provider refund of the latest payment path (gateway-specific). |
| Access | Installation stops being usable quickly (soft-deleted / suspended). |
| Data retention | Short window (default 7 days) then hard delete. |
| Backups | Purged on hard delete path. |
| Re-open | Not a simple “undo”; customer would need a new installation/checkout. |
Contraste avec les autres sorties
| Action | Typical effect |
|---|---|
| Cancel renewal | Runs until period end; then soft-delete with longer retention |
| Approved refund | Immediate terminate path; shorter hard-delete (default 7 days) |
| ToS suspend (admin) | Offline; no automatic refund |
| Payment failure | Grace banner → suspend → soft-delete rules |
Organisations et sièges
Organisation personnelle
Créé automatiquement lors de l’inscription. L’utilisateur est le propriétaire. Les limites proviennent de :
- Admin → Paramètres → Déploiements → installations maximales par défaut / sièges maximaux
- Ou les remplacements par l’administrateur sur l’enregistrement de l’organisation
Organisations d’équipe
Les propriétaires/administrateurs peuvent créer des organisations d’équipe (voir l’interface utilisateur de l’organisation du client). Les sièges et les plafonds d’installation s’appliquent par organisation.
Rôles
| Role | Typical powers |
|---|---|
| Owner | Full org control, billing, members |
| Admin | Manage members & installs |
| Member | Work on installations (no full billing admin) |
| Billing | Billing-focused access |
Les portes exactes suivent les politiques de l’application ; traitez le propriétaire/l’administrateur comme privilégié.
Invitations
- Invite les utilisateurs existants de la plateforme (l’e-mail doit déjà être associé à un compte).
- Il n’existe pas d’e-mail d’invitation MVP qui crée un compte à partir de zéro.
- Vérification du siège : impossible d’inviter au-delà de max_seats.
Les administrateurs remplacent les paramètres
Les administrateurs de plateforme peuvent augmenter/diminuer max_seats et max_installations par organisation depuis l’interface utilisateur des organisations d’administration, lorsque disponible.