Un fournisseur d’accès a deux sources de vérité : le système de facturation et le routeur. L’automatisation de la facturation MikroTik consiste à les garder d’accord, et les bugs coûteux se logent dans l’écart entre les deux : un client qui a payé mais reste coupé, un client qui ne paie plus mais reste en ligne, ou un renouvellement appliqué deux fois parce qu’une passerelle a renvoyé son webhook. Quand nous avons construit Linkhive, notre plateforme de facturation Laravel auto-hébergée pour les fournisseurs haut débit et Wi-Fi, ces trois pannes ont façonné la conception plus que n’importe quelle fonction.
L’automatisation de la facturation MikroTik commence par des étapes répétables
Le cycle de facturation de Linkhive est une liste ordonnée d’étapes : créer les factures de renouvellement, renouveler depuis le solde prépayé, traiter les factures payées, envoyer les rappels, faire expirer et suspendre, puis gérer les bons. Le planificateur le lance toutes les 15 minutes, et sur un hébergement sans cron, le même cycle s’exécute via le trafic web, au plus toutes les 15 minutes.
Des exécutions fréquentes ne sont sûres que si une seconde exécution ne change rien. Chaque étape vérifie donc si son travail est déjà fait. Avant de facturer un renouvellement, elle cherche une facture pour ce client, ce forfait et cette période. Avant d’envoyer un rappel, elle regarde dans le journal des messages si un rappel est parti aujourd’hui. Chaque étape tourne aussi dans son propre try/catch : l’échec est journalisé et les autres étapes continuent, donc un enregistrement défectueux n’arrête pas toutes les suspensions du réseau.
Les délais sont configurables. Par défaut, la facture est émise trois jours avant l’expiration, les rappels partent trois jours et un jour avant, et le service s’arrête après deux jours de grâce.
Une mise à jour atomique empêche le double renouvellement
Un même paiement peut arriver par trois voies à la fois : le navigateur du client qui revient de la passerelle, le webhook de la passerelle et le cycle de facturation qui reprend une facture payée. Si chaque voie vérifie « est-ce déjà renouvelé ? » puis renouvelle, deux d’entre elles peuvent passer le contrôle ensemble et le client obtient deux mois pour le prix d’un.
Une vérification suivie d’une écriture laisse cet écart, nous avons donc réuni les deux en une seule instruction :
$claimed = Invoice::whereKey($invoice->id)
->whereNull('fulfilled_at')
->update(['fulfilled_at' => now()]);
if ($claimed === 0) {
return false; // another request got here first
}La base de données ne laisse qu’un seul UPDATE toucher cette ligne, quelle que soit la requête arrivée en premier. Les autres voient zéro ligne modifiée et s’arrêtent. Les paiements sont traités de la même façon : approvePayment() verrouille la ligne avec lockForUpdate() dans une transaction, donc deux appels n’appliquent l’argent qu’une fois.
Interroger la passerelle, jamais le navigateur
Tout ce qui arrive sur une URL de retour peut être falsifié : ce n’est donc qu’un indice. Pour Stripe, Linkhive enregistre l’identifiant de la session Checkout au début du paiement, puis récupère cette session via l’API de Stripe au retour. L’argent n’est enregistré que si la session correspond et que Stripe la déclare payée, avec la bonne référence, le montant exact et la bonne devise. PayPal suit le même modèle, et les pilotes SSLCommerz, bKash et Nagad confirment le montant et la référence via leurs propres API.
Un routeur hors ligne ne doit pas annuler un paiement
La conception tentante parle au routeur à l’intérieur de la transaction de paiement. Un redémarrage du routeur transforme alors un paiement réussi en page d’erreur. Dans Linkhive, chaque changement sur un routeur passe par une seule classe, Provisioner, qui ne lève jamais d’exception. L’argent est enregistré d’abord. Si le routeur est injoignable, l’échec est écrit dans un journal de provisionnement et l’abonnement est marqué pour une nouvelle tentative.
Une tâche horaire reprend les abonnements marqués pendant trois jours au maximum. Elle lit l’état actuel de l’abonnement au lieu de rejouer l’ancienne commande : un abonnement actif est activé, tout autre est suspendu. Si un client a payé pendant la panne du routeur, la reprise le reconnecte et n’applique pas la suspension périmée.
Pour l’automatisation de la facturation MikroTik, le pilote passe par l’API RouterOS, sur le port 8728 ou en TLS sur le 8729, avec un client que nous avons écrit nous-mêmes. Il met à jour /ppp/secret pour le PPPoE ou /ip/hotspot/user pour le hotspot, puis coupe la session active pour que le client se reconnecte avec le bon profil. FreeRADIUS se trouve derrière la même interface de pilote : le code de facturation ne se soucie pas de ce qu’utilise le fournisseur.
Le prouver avec des tests qui attaquent les règles
Ces règles échouent en silence : l’automatisation de la facturation MikroTik a donc besoin de tests qui tentent de les casser. Linkhive inclut 147 tests automatisés qui passent sur SQLite et MySQL 8.4. Ils relancent le cycle pour vérifier l’idempotence, envoient de faux retours de passerelle et essaient des montants et devises incohérents. L’analyse statique avec Larastan au niveau 5 ne signale aucune erreur.
À retenir
- Écrivez les étapes pour qu’une seconde exécution ne change rien, puis lancez-les souvent.
- Réservez le travail avec un seul
UPDATEatomique, pas une lecture suivie d’une écriture. - Confirmez chaque paiement via l’API de la passerelle, y compris le montant et la devise.
- Gardez les appels au routeur hors des transactions de paiement et enregistrez les échecs pour reprise.
- Reprenez depuis l’état actuel, jamais en rejouant une ancienne commande.
Vous pouvez tout voir dans la démo en ligne de Linkhive, lire la présentation des fonctions sur Charming Theme ou obtenir Linkhive sur Vibe96.
Vous gérez un réseau haut débit ou Wi-Fi et les tableurs ne suffisent plus ? Parlons-en. ArtinTech Solution réalise ce type de facturation et d’intégration avec notre service de développement Laravel.