إدارة الاشتراكات والعضويات في SaaS بـ Go: البنية والتحديات

إدارة الاشتراكات تبدو بسيطة حتى تواجه اشتراكًا متأخرًا في الدفع، وترقية خلال منتصف دورة الفوترة، وعميلًا يريد إلغاء الاشتراك لكن مع الاحتفاظ بالبيانات حتى نهاية الفترة المدفوعة، ومستأجرًا لم يتجاوب مع ثلاث رسائل تذكير متتالية.

ما هي حالات دورة الحياة التي يجب أن يتعامل معها النظام؟

• trialing: فترة تجريبية، الوصول ممنوح بدون دفع
• active: اشتراك نشط، الدفع ناجح
• past_due: تأخر في الدفع، لا يزال يملك الوصول خلال فترة السماح
• suspended: تعليق الوصول بعد استنفاد فترة السماح
• cancelled: إلغاء من قبل المستخدم
• expired: انتهاء الفترة المدفوعة

كيف تصمم قاعدة البيانات؟

CREATE TABLE subscriptions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id       UUID NOT NULL UNIQUE,
    plan_id         UUID NOT NULL,
    status          TEXT NOT NULL DEFAULT 'trialing',
    current_period_start TIMESTAMPTZ NOT NULL,
    current_period_end   TIMESTAMPTZ NOT NULL,
    cancel_at_period_end BOOLEAN NOT NULL DEFAULT false
);

كيف تتعامل مع فشل الدفع وآلية dunning؟

النمط القياسي:

• اليوم 0: فشل الدفع، الاشتراك ينتقل إلى past_due
• اليوم 3: إعادة محاولة تلقائية
• اليوم 7: إعادة محاولة ثانية، تحذير التعليق
• اليوم 14: تعليق الوصول
• اليوم 30: إلغاء نهائي

وظيفة التجديد تعمل كمهمة مجدولة يومية تتحقق من جميع الاشتراكات التي يحين موعد تجديدها أو إعادة محاولة الدفع.

كيف تتحكم في الوصول؟

middleware للتحقق من حالة الاشتراك في كل طلب يمنع المستخدمين المعلقين من الوصول مع السماح لـ past_due بفترة سماح.

الدروس الرئيسية من الإنتاج

إدارة الاشتراكات ليست ميزة واحدة، هي نظام فرعي كامل. حالات دورة الحياة يجب أن تكون صريحة ومخزنة. منطق dunning يجب أن يكون قابلًا للتهيئة. التحكم في الوصول بناءً على حالة الاشتراك في middleware وليس في كل نقطة نهاية.

هل تحتاج إلى مساعدة في بناء SaaS؟

فوكسير تصمم وتبني منصات SaaS كاملة للشركات في لبنان ومنطقة الشرق الأوسط وشمال إفريقيا.

https://voxire.com/get-a-quote/