Herkese Açık Bir SaaS Motoru Geliştirmek: Sabit Kodlanmış Bir Plan Olmayan Bir Ortaklık Programı

Bu makalede, bir SaaS uygulamasında (Software as a Service) ortaya konan önemli yapıların başında gelen bir ortaklık programının nasıl tamamlandığına değineceğiz. Ortaklık programı, genellikle özel bir durum olarak inşa edilip sonradan pişmanlık duyulabilen bir bileşendir. Amaç, bu makaleyi okuyarak bu tür bir pişmanlığı en aza indirgeyerek tamamlanmış bir sistem ortaya koymak.

LaraFoundry, halihazırda üretimde çalışan bir CRM’den (Müşteri İlişkileri Yönetimi) adım adım çıkardığım yeniden kullanılabilir bir Laravel SaaS çekirdeğidir. Bu çekirdek, sadece para ile ilgili ek bileşenler dışında ücretsizdir. Bir işletmenin kendi müşterilerinden ücret almaya karar verdikleri gün, bu ücretli faturalama eklentisi olacaktır. Bir ortaklık programı ise doğrudan bu ücretli kısımda yer alır: Mevcut faturalama motorunun üzerine gelir sağlayan bir yol sunar.

Burada “tamam” demek somut olarak şunu ifade ediyor: benzersiz bir yönlendirme kodu olan bir ortak kimliği, yeni bir kiracıyı yönlendiren ortağa atfeden bir bağlantı, yönlendirilmiş kiracı ödendiğinde birikir hale gelen komisyon, bu ödeme iade edildiğinde veya başarısız olduğunda geri çekme, her para birimi için toplamlar ve bir CSV dışa aktarma olan bir süper admin ödeme konsolu, ve bir ortakın kendi yönlendirme ve bakiyesini görebileceği bir kendine hizmet paneli. Tüm bunlar, 314 Pest testi altında gerçekleşiyor.

Birinci karar: bir motor, bir plan değil

Kolay olanı yaparak bir ortaklık programı inşa etmek, istediğiniz yapıyı kodlamak olurdu. Yüzde yirmi, tekrar eden, her faturada ödenen bir yapı. Bu yöntem çalışır, bir günde tamamlanabilir, fakat bu durum tüm kullanıcıları kendi komisyon politikalarınıza zorlar. Yeniden kullanılabilir bir çekirdek bunu yapamaz. Bunun yerine, ben de bir program yapmadım; üç eksen boyunca yapılandırılmış bir motor oluşturdum. Bu eksenler birbirlerini tanımıyor.

'affiliate' => [
            'enabled'     => true,
            'eligibility' => 'auto',          // auto | self_serve | admin
            'commission'  => [
                'trigger'       => 'recurring', // first_payment | recurring | lifetime
                'window_months' => 12,
                'basis'         => 'per_plan',  // per_plan | percent | fixed
            ],
        ],
        

Uygunluk, kimin ortak olacağını belirler. auto her kullanıcı için bir kod oluşturur, böylece herkes bir bağlantı paylaşabilir. self_serve kullanıcıların katılmasına izin verir, ancak onay bekletir. admin ise davetiyeli ortakları ifade eder. “Trigger” ise hangi ödemenin ödeneceğini belirler. first_payment referans başına bir defalık ödül verir. recurring belirli bir süre boyunca ödeme yapmaya devam eder; varsayılan olarak on iki aydır, daha sonra durur. lifetime ise sonsuza kadar devam eder. Temel, miktarın nasıl belirleneceğini ifade eder. per_plan komisyon miktarını plan sözlüğünden okur; percent net ödemenin bir payını alır; fixed ise sabit bir ücreti temsil eder. Her ortak için özel bir ayar, belirli bir ortağın oranını artırabilir veya azaltabilir.

Üç eksen birbirinden bağımsız olduğu için, her kombinasyon geçerli ve motor bununla karmaşık bir yapı haline gelmiyor. Komisyon motoru, tüm bu kurgusal ayrımlar göz önünde bulundurularak yapılandırılmıştır.

İkinci karar: sıfır host kodu

En çok memnun kaldığım kısım, bir ortaklık programını etkinleştirmenin host uygulamasına tek bir satır PHP eklememesidir. Bu, ortaklık programından önce var olan iki olaya dayanıyor.

// Ücretsiz çekirdek, bir kiracı yaratıldığında tetiklenir.
        event(new CompanyCreated($company, $owner));

        // Ücretli eklenti, bir şirket ödemesi işlendiğinde tetiklenir.
        event(new CompanyPaymentProcessed($payment));
        

CompanyCreated, ücretsiz çekirdeğin bir parçasıdır. Bu, faturalama veya ortaklıklar ile ilgili olmayacak şekilde her kayıt işleminde tetiklenir. CompanyPaymentProcessed ise eklentinin kendi olayıdır ve bir ödemenin işlem gördüğü anı belirtir. Bu iki olay, ortaklık programı için yaratılmamıştır; ortaklık programı sadece bu olaylara abone olmuştur.

Event::listen(CompanyCreated::class, AttributeReferral::class);
        Event::listen(CompanyPaymentProcessed::class, AccrueAffiliateCommission::class);
        

AttributeReferral, yönlendirme çerezini okuyarak yeni şirketi bir ortakla kilitler. AccrueAffiliateCommission, tetikleme ve temel mantığını çalıştırır ve bir komisyon kaydı yazar. Her iki dinleyici ve bunların arkasındaki motor, özel bir eklentinin parçasıdır; bu yüzden onları burada açıklıyorum. Eklenti, bu dinleyicileri kendi hizmet sağlayıcısından, affiliate.enabled bayrağının arkasında kayıt eder. Bir host, özelliği yapılandırmada etkinleştirir, iki Inertia sayfasını yayınlar ve işini tamamlar. Yazılması gereken bir denetleyici yok, elde ateşlenmesi gereken bir olay yok ve bir model ile işiniz yok. Bağlantı, çekirdekte zaten mevcut; eklenti oraya bağlanıyor.

Atıf bir kez kilitlenir, bir oracle değildir

Yönlendirme bağlantısı /r/{code} şeklindedir. Bu bağlantıya tıklandığında, şifreli bir çerez bırakılır ve yönlendirme yapılır. Yönlendirme her koşulda standarttır; gerçek ya da geçersiz bir kod olması durumunda bile aynı yere gider. Bu sayede, hedef nokta geçerli kodları belirlemek için bir oracle haline gelmez. O ziyaretçi daha sonra bir şirket oluştuğunda, AttributeReferral tetiklenir.

Atıf bir kez kilitlenir. Bir şirketi yönlendiren ilk ortak, onu alır; daha sonraki bir bağlantı mevcut bir kiracıyı çalamaz, çünkü yönlendirme kaydı yönlendirilmiş şirket üzerinde benzersiz bir anahtara sahiptir. Kendini yönlendirme engellenir, böylece bir ortak kendi kodu altında kaydolamaz. Ve ortak, first_payment tetiklemesi altında her yönlendirme için yalnızca bir ödül alır; bu sayede bir sıradışı yanıt veya yanlış sıralı bir ağ geçidi ödeme iki ödül kazanamaz. Bu, teslim edilmeden önce bir güvenlik gözden geçirme aşamasında ortaya çıkmış bir hata idi; aynı kayıt ikdosu referans başına bir tane olması gerektiği şeklinde düzeltildi. Şu anki testler bunu korumaktadır.

Para dürüst kalır

Komisyonlar, her bir para birimi için, tam sayılar olarak saklanır ve hiçbir yerde dönüştürücü yoktur. Bu, faturalama motoru ile aynı kuralı takip eder. Bir ortak, euro, zloty, ve dolar gibi farklı para birimleriyle ödeme yapan müşterileri yönlendirdiğinde, üç ayrı bakiye birikir; konsol bu üç ayrı toplamı raporlar. Herhangi bir döviz çevirici, gerçek parayı yaklaşık bir değer haline getirmez.

Ödemeler, kasıtlı olarak manuel olarak kontrol edilir ve bunun bir özellik olduğunu belirtmek isterim, bir eksiklik değildir. Eklenti, herhangi bir para çıkışını sağlayan bir ödeme aracısına sahip değildir ve bunun olabileceğini iddia etmez. Yöneticilere, kimin neye sahip olduğunu gösteren bir rapor sunar. Bir komisyon, birikirken pending durumuna geçer. Yöneticiler bir grubu onayladığında (pending‘den approved‘a), daha sonra beklemeden çıkarken durum düşürülür ve bir ödeme referansı eklenir (approved‘dan paid‘a). İlgili komisyon, otomatik geri çekme işlemiyle hesaplanamazsa manuel olarak iptal edilebilir.

Konsol, mevcut filtrelenmiş raporu bir CSV olarak dışa aktarır ve bu CSV, tabloya formül enjeksiyonunu nötralize eder. Tehlikeli karakterlerle başlayan her hücre, bir formül olarak değil metin olarak işlenmesi için eklenir. Dolayısıyla bir ödemenin referansı, Excel’de yürütülmemelidir.

İki kullanıcı arayüzü

İki UI yüzeyi bulunmaktadır; her ikisi de hostun yayınladığı Inertia ve Vue sayfalarıdır. Bu, çekirdeğin geri kalanının ön yüzüyle aynı dağıtım modelini takip eder; böylece eklenti, ikinci bir inşa boru hattı.getirmez.

Süper admin, ödeme konsoluna sahiptir. Bu, durumlarına göre toplamları olan komisyon raporu, toplu onaylama, ödenmiş olarak işaretleme ve iptal işlemleri ile CSV dışa aktarma özelliklerini içerir. Ortak kendi kullanıcı kimliğine sıkı bir şekilde sınırlandırılmış bir kendi kendine hizmet panosuna sahip olur: kendi kodu, yönlendirmeleri ve her para birimiyle durumuna göre bakiyesi burada bulunur. Panoda başka bir ortağın verileri asla sızamaz, bu testler tarafından doğrudan koruma altına alınmıştır.

Kanıt, çünkü her sürüm bir kanıt içerir

314 Pest testi, Pint temiz, ve iki ajanlı bir adversary incelemesi (biri güvenlik için, diğeri doğruluk için) bu işin tamamlandığını onaylamadan önce yapılmıştır. Güvenlik değerlendirmesi önemli bulgular içermedi; ortak panosunun kapsamı sıkı, konsol üç yönlendirmeyle güvence altına alınmıştı ve durum makinesi kimlik değişimi ile güvenlidi. Doğruluk değerlendirmesi, yukarıda açıkladığım hatalı ödemeyi ve daha sessiz bir hata buldu: bir çevre değişkeni ile sağlanan bir yüzde, bir dize olarak geldi ve sayı dizesi reddedildi. Bu ikisi, geriye dönük testler ile düzeltildi. Ödeme ile güvenmeyebileceğiniz bir program, hiç olmaması kadar kötü bir durumdur ve burada konuşulan hataların çoğu sessizce meydana gelebilir.

Dürüstlük bölümü

Bu seride her makale, bir dürüstlük bölümü içerir. Bu yeni kod, uzun zamandır kanıtlanmış kod değil. Ortaklık programının altında yatan çekirdek, üretimde çalışan bir CRM’den çıkarılmıştır. Fakat ortaklık motoru, yeni bir dönem için yazılmış, testler ile kanıtlanmış bir yapıdır. O, CompanyPaymentProcessed olayına dayanır ve bu, oluşturup test ettiğim ancak henüz canlı bir işletme hesabına karşı çalıştırmadığım faturalama ağ geçitlerim tarafından sürdürülmektedir. Bu yüzden, komisyonların kazanılıp ödenmediğini söylemeyeceğim; çünkü bu henüz olmadı. Ancak 314 testte kazanılıp ödendi.

Bu yapı bir motor, tam bir ortaklık platformu değil. Automatize edilmiş para çıkışı, dolandırıcılık değerlendirmesi, aşamalı ortaklık yapısı yok. Bunlar ilk versiyonu için kasıtlı olarak bir hedef olarak belirlenmedi. Burada yer alan şey ise omurga; atıf, yapılandırılabilir bir kazanım motoru, geri çekme, bir ödeme konsolu ve bir ortak paneli, böylece bir host bunu büyütebilir.

Yine ip

Bu serinin her aşaması aynı yapıda sonuçlanır. İlginç mühendislik, doğru olabilir, fakat asıl ders her zaman bir uygulama için doğru veya başka bir uygulama için yanlış olan varsayılan ayardır. Ortaklık programı için bu, komisyon planının kendisiydi. Çıkarıldığı CRM, yalnızca bir politika gerektirecektir; çünkü yalnızca bir işletmeyi hizmet eder ve yirmi yüzde tekrar eden bir yapıyı kodlamak orada tamamen makul olurdu. Yeniden kullanılabilir bir çekirdek için ise bu, herkesin politikası haline gelirdi. Asıl iş, yönlendirme takibi oluşturmak değil; bir şirketin neye sahip olduğu fikrini yerleştirme kararını vermek ve tüm sistemin bir hostun kodunu etkilemeden açılmasını sağlamak idi.

Takip edin