En internetudbyder har to sandhedskilder: faktureringssystemet og routeren. MikroTik-faktureringsautomatisering handler om at holde dem enige, og de dyre fejl ligger i kløften mellem dem: en kunde, der har betalt, men stadig er afbrudt, en kunde, der er holdt op med at betale, men stadig er online, eller en fornyelse, der bliver anvendt to gange, fordi en betalingsgateway gentog sin webhook. Da vi byggede Linkhive, vores selvhostede Laravel-faktureringsplatform til bredbånds- og Wi-Fi-udbydere, formede disse tre fejl designet mere end nogen funktion.
MikroTik-faktureringsautomatisering starter med trin, der kan køre to gange
Linkhives faktureringscyklus er en ordnet liste af trin: opret fornyelsesfakturaer, forny automatisk fra forudbetalt saldo, gennemfør betalte fakturaer, send påmindelser, lad udløbe og suspender, og håndter derefter vouchers. Planlæggeren kører den hvert 15. minut, og på hosting uden cron kører samme cyklus fra webtrafik højst hvert 15. minut.
Hyppige kørsler er kun sikre, hvis en ny kørsel ikke ændrer noget. Derfor spørger hvert trin, om arbejdet allerede er gjort. Før en fornyelse faktureres, søges der efter en faktura for samme kunde, pakke og periode. Før en påmindelse sendes, tjekkes beskedloggen for en, der er sendt i dag. Hvert trin kører også i sin egen try/catch: en fejl logges, og de øvrige trin fortsætter, så én dårlig post ikke kan stoppe alle suspenderinger på netværket.
Tidspunkterne kan konfigureres. Som standard oprettes fakturaen tre dage før udløb, påmindelser sendes tre dage og én dag før, og tjenesten stopper efter to henstandsdage.
Én atomar opdatering stopper en dobbelt fornyelse
Én betaling kan nå systemet ad tre veje på én gang: kundens browser, der vender tilbage fra gatewayen, gatewayens webhook og faktureringscyklussen, der samler en betalt faktura op. Hvis hver vej tjekker “er dette fornyet?” og derefter fornyer, kan to af dem bestå tjekket samtidig, og kunden får to måneder til prisen for én.
Et tjek efterfulgt af en skrivning efterlader det hul, så vi gjorde tjek og skrivning til én sætning:
$claimed = Invoice::whereKey($invoice->id)
->whereNull('fulfilled_at')
->update(['fulfilled_at' => now()]);
if ($claimed === 0) {
return false; // another request got here first
}Databasen lader kun én UPDATE ramme rækken, uanset hvilken anmodning der kommer først. De andre ser nul berørte rækker og stopper. Betalinger behandles på lignende vis: approvePayment() låser rækken med lockForUpdate() i en transaktion, så to kald kun anvender pengene én gang.
Spørg gatewayen, aldrig browseren
Alt, der ankommer på en retur-URL, kan forfalskes, så det behandles kun som et hint. For Stripe gemmer Linkhive Checkout-sessionens ID, når betalingen starter, og henter sessionen fra Stripes API ved retur. Pengene bogføres kun, hvis sessionen matcher, og Stripe melder den betalt med rigtig reference, præcist beløb og rigtig valuta. PayPal følger samme mønster, og driverne til SSLCommerz, bKash og Nagad bekræfter beløb og reference med deres egne API’er.
En offline router må ikke rulle en betaling tilbage
Det fristende design taler med routeren inde i betalingstransaktionen. Så bliver en genstart af routeren til en fejlside efter en vellykket kortbetaling. I Linkhive går hver routerændring gennem én klasse, Provisioner, og den kaster aldrig fejl. Pengene registreres først. Kan routeren ikke nås, skrives fejlen i en provisioneringslog, og abonnementet markeres til nyt forsøg.
Et timejob prøver markerede abonnementer igen i op til tre dage. Det læser abonnementets aktuelle tilstand i stedet for at gentage den gamle kommando: et aktivt abonnement aktiveres, og alle andre suspenderes. Hvis en kunde betalte, mens routeren var nede, genforbinder forsøget kunden og anvender ikke den forældede suspendering.
Til MikroTik-faktureringsautomatisering arbejder driveren gennem RouterOS API, på port 8728 eller over TLS på 8729, med en klient vi selv har skrevet. Den opdaterer /ppp/secret for PPPoE eller /ip/hotspot/user for hotspot-brugere og afbryder derefter den aktive session, så kunden genforbinder med den rigtige profil. FreeRADIUS ligger bag samme driverinterface, så faktureringskoden er ligeglad med, hvilken en udbyder bruger.
Bevis det med test, der angriber reglerne
Sådanne regler fejler lydløst, så MikroTik-faktureringsautomatisering kræver test, der forsøger at bryde dem. Linkhive leveres med 147 automatiske test, der består på SQLite og MySQL 8.4. De kører faktureringscyklussen gentagne gange for at tjekke idempotens, sender forfalskede gateway-returneringer og prøver afvigende beløb og valutaer. Statisk analyse med Larastan på niveau 5 viser ingen fejl.
Vigtigste pointer
- Skriv faktureringstrin, så en ny kørsel intet ændrer, og kør dem ofte.
- Reservér arbejde med en enkelt atomar
UPDATE, ikke en læsning efterfulgt af en skrivning. - Bekræft hver betaling med gatewayens API, inklusive beløb og valuta.
- Hold routerkald ude af betalingstransaktioner, og registrér fejl til nyt forsøg.
- Prøv igen ud fra aktuel tilstand, aldrig ved at gentage en gammel kommando.
Du kan se det hele i Linkhive live-demoen, læse funktionsoversigten på Charming Theme eller købe Linkhive på Vibe96.
Driver du et bredbånds- eller Wi-Fi-net og er vokset fra regnearkene? Lad os tale sammen. ArtinTech Solution bygger denne type fakturering og integration gennem vores Laravel-udvikling.