Automasi Pengebilan MikroTik: Menjadikan Pembaharuan Selamat Diulang

Penyedia internet mempunyai dua sumber kebenaran: sistem pengebilan dan penghala. Automasi pengebilan MikroTik ialah kerja memastikan kedua-duanya sepakat, dan pepijat yang mahal berada di jurang antara keduanya: pelanggan yang sudah membayar tetapi masih terputus, pelanggan yang berhenti membayar tetapi masih dalam talian, atau pembaharuan yang digunakan dua kali kerana get laluan bayaran mengulang webhook. Semasa membina Linkhive, platform pengebilan Laravel hos sendiri kami untuk penyedia jalur lebar dan Wi-Fi, tiga kegagalan ini membentuk reka bentuk lebih daripada mana-mana ciri.

Automasi pengebilan MikroTik bermula dengan langkah yang selamat dijalankan dua kali

Kitaran pengebilan Linkhive ialah senarai langkah tertib: cipta invois pembaharuan, perbaharui automatik daripada baki prabayar, selesaikan invois berbayar, hantar peringatan, tamatkan dan gantung, kemudian uruskan baucar. Penjadual menjalankannya setiap 15 minit, dan pada hosting tanpa cron kitaran yang sama berjalan daripada trafik web paling kerap setiap 15 minit.

Larian kerap hanya selamat jika larian kedua tidak mengubah apa-apa. Jadi setiap langkah bertanya sama ada kerjanya sudah selesai. Sebelum membilkan pembaharuan, ia mencari invois untuk pelanggan, pakej dan tempoh itu. Sebelum menghantar peringatan, ia menyemak log mesej untuk peringatan yang dihantar hari ini. Setiap langkah juga berjalan dalam try/catch sendiri: kegagalan dilog dan langkah lain tetap berjalan, jadi satu rekod rosak tidak dapat menghentikan semua penggantungan di rangkaian.

Masa boleh dikonfigurasi. Secara lalai, invois dikeluarkan tiga hari sebelum tamat, peringatan dihantar tiga hari dan satu hari sebelumnya, dan perkhidmatan berhenti selepas dua hari tangguh.

Satu kemas kini atomik menghentikan pembaharuan berganda

Satu bayaran boleh sampai ke sistem melalui tiga laluan serentak: pelayar pelanggan yang kembali dari get laluan, webhook get laluan, dan kitaran pengebilan yang mengambil invois berbayar. Jika setiap laluan menyemak “sudah diperbaharui?” lalu memperbaharui, dua daripadanya boleh lulus semakan bersama dan pelanggan mendapat dua bulan pada harga sebulan.

Semakan diikuti tulisan meninggalkan jurang itu, jadi kami jadikan semakan dan tulisan satu pernyataan:

$claimed = Invoice::whereKey($invoice->id)
    ->whereNull('fulfilled_at')
    ->update(['fulfilled_at' => now()]);

if ($claimed === 0) {
    return false; // another request got here first
}

Pangkalan data hanya membenarkan satu UPDATE sepadan dengan baris itu, tidak kira permintaan mana tiba dahulu. Yang lain melihat sifar baris terjejas dan berhenti. Bayaran dilayan serupa: approvePayment() mengunci baris dengan lockForUpdate() dalam transaksi, jadi memanggilnya dua kali hanya mengenakan wang sekali.

Tanya get laluan, bukan pelayar

Apa-apa yang tiba pada URL kembali boleh dipalsukan, jadi ia hanya dianggap petunjuk. Untuk Stripe, Linkhive menyimpan ID sesi Checkout apabila bayaran bermula, kemudian mengambil sesi itu daripada API Stripe semasa kembali. Wang direkodkan hanya jika sesi sepadan dan Stripe melaporkannya dibayar, dengan rujukan betul, jumlah tepat dan mata wang betul. PayPal mengikut corak sama, dan pemacu SSLCommerz, bKash dan Nagad mengesahkan jumlah dan rujukan dengan API masing-masing.

Penghala di luar talian tidak boleh membatalkan bayaran

Reka bentuk yang menggoda berkomunikasi dengan penghala di dalam transaksi bayaran. Akibatnya, but semula penghala menukar bayaran kad yang berjaya menjadi halaman ralat. Dalam Linkhive, setiap perubahan penghala melalui satu kelas, Provisioner, dan ia tidak pernah melontar ralat. Wang direkodkan dahulu. Jika penghala tidak dapat dicapai, kegagalan ditulis dalam log peruntukan dan langganan ditanda untuk dicuba semula.

Tugas setiap jam mencuba semula langganan bertanda sehingga tiga hari. Ia membaca keadaan semasa langganan, bukan mengulang arahan lama: langganan aktif diaktifkan dan yang lain digantung. Jika pelanggan membayar semasa penghala tergendala, cubaan semula menyambungkan mereka dan tidak menggunakan penggantungan lapuk.

Untuk automasi pengebilan MikroTik, pemacu bekerja melalui API RouterOS, pada port 8728 atau melalui TLS pada 8729, dengan klien yang kami tulis sendiri. Ia mengemas kini /ppp/secret untuk PPPoE atau /ip/hotspot/user untuk hotspot, kemudian memutuskan sesi aktif supaya pelanggan bersambung semula dengan profil betul. FreeRADIUS berada di belakang antara muka pemacu yang sama, jadi kod pengebilan tidak peduli yang mana digunakan penyedia.

Buktikan dengan ujian yang menyerang peraturan

Peraturan seperti ini gagal secara senyap, jadi automasi pengebilan MikroTik memerlukan ujian yang cuba memecahkannya. Linkhive disertakan 147 ujian automatik yang lulus pada SQLite dan MySQL 8.4. Ujian menjalankan kitaran berulang kali untuk menyemak idempotensi, menghantar pemulangan palsu dan mencuba jumlah serta mata wang yang tidak sepadan. Analisis statik dengan Larastan tahap 5 tidak melaporkan ralat.

Perkara utama

• Tulis langkah pengebilan supaya larian kedua tidak mengubah apa-apa, kemudian jalankan dengan kerap.
• Tuntut kerja dengan satu UPDATE atomik, bukan bacaan diikuti tulisan.
• Sahkan setiap bayaran dengan API get laluan, termasuk jumlah dan mata wang.
• Jauhkan panggilan penghala daripada transaksi bayaran, dan rekod kegagalan untuk dicuba semula.
• Cuba semula daripada keadaan semasa, bukan dengan mengulang arahan lama.

Anda boleh melihat semuanya dalam demo langsung Linkhive, membaca gambaran ciri di Charming Theme, atau mendapatkan Linkhive di Vibe96.

Mengendalikan rangkaian jalur lebar atau Wi-Fi dan hamparan tidak lagi mencukupi? Mari berbincang. ArtinTech Solution membina kerja pengebilan dan integrasi seperti ini melalui perkhidmatan pembangunan Laravel kami.