SaaS için yönlendirme kredi sistemi tasarımı: yönlendirmeleri izleyin, suistimali engelleyin ve anlaşılır kurallar ile denetlenebilir bir defterde kredileri aboneliklere uygulayın.
Yönlendirme kredi programı bir faturalama özelliğidir, ödeme özelliği değil. Ödül, gelecekteki ücretleri azaltan (veya süreyi uzatan) hesap kredisi olarak verilir. Bankaya gönderilen nakit, hediye kartı veya "daha sonra ödeme yapılacak" sözü değildir.
İyi bir sistem her seferinde tek bir soruya cevap verir: "Bu hesabın bir sonraki faturası neden düştü?" Bunu bir veya iki cümlede açıklayamıyorsanız, support talepleri ve itirazlar gelir.
Bir yönlendirme kredi sistemi üç parçadan oluşur: birisi yeni bir müşteri davet eder, net kurallar davetin ne zaman sayılacağını belirler (dönüşüm), ve krediler kazanılır ve gelecekteki abonelik faturalarına uygulanır.
Ne değildir: nakit ödeme, kayıtsız şekilde sayıları değiştiren belirsiz bir indirim veya hiç faturaya bağlanmayan puan sistemi değildir.
Birçok ekip bu detaylara güvenir. Yönlendirenler ne kazandıklarını ve ne zaman uygulanacağını görmek ister. Yönlendirilenler ne aldıklarını ve planlarını etkileyip etkilemediğini bilmek ister. Destek "kreditim neden kayboldu" sorusunu hızlı çözmelidir. Finans, faturalarla uyuşan ve denetlenebilir toplamlar ister.
Örnek: Sam, Priya'yı yönlendirir. Priya ücretli bir plana başlar. Sam, bir sonraki faturasından en fazla 20$ azaltacak şekilde 20$ kredi kazanır. Eğer Sam'in bir sonraki faturası 12$ ise kalan 8$ sonraki kullanımlar için kredide kalır ve kaynağı açık bir kayıtla belirtilir.
Başarı sadece "daha çok yönlendirme" değildir. Başarı öngörülebilir faturalama ve daha az anlaşmazlıktır. Sistem işe yarıyorsa kredi bakiyeleri kolayca açıklanır, faturalar defterle eşleşir ve destek tahmin veya manuel düzeltme yapmadan soruları yanıtlayabilir.
Yönlendirme programı basit gibi görünür; ta ki ilk talepler gelene kadar: "Neden kredim yok?" İşin çoğu koddan çok politika ile ilgilidir.
Tetikleyici ile başlayın. "Davet gönderildi" çok erken bir noktadır. "Kaydoldu" ise sahte hesaplarla suistimal için kolaydır. Yaygın bir orta yol "nitelikli dönüşüm"dür: e-posta doğrulandı artı ilk ücretli fatura, veya deneme sonrası ilk başarılı ödeme. Bir tetik seçin ve tutarlı kalın ki defteriniz temiz kalsın.
Sonra değer ve sınırları belirleyin. Krediler gerçek hissettirmeli, ama sınırsız bir indirim makinesi olmamalı. Sabit bir miktar mı verileceğine (ör. 20$ kredi) yoksa faturanın yüzdesi mi olacağına ve bunu bir cümlede açıklayabileceğiniz şekilde sınırlandırmaya karar verin.
Daha sonra kafa karışıklığını önleyen kararlar:
Uygunluk kuralları beklenenden daha önemlidir. Sadece ücretli planlar sayılıyorsa bunu belirtin. Bazı bölgeler hariçse (vergi, uyumluluk, promosyonlar), bunu söyleyin. Yıllık planlar uygunken aylık planlar değilse bunu belirtin. Koder.ai gibi bir platform için birden fazla katman varsa, ücretsizten pro'ya yükseltmelerin uygun olup olmadığı ve kurumsal sözleşmelerin manuel olarak mı ele alınacağına önceden karar verin.
Kullanıcıya yönelik metni yayınlamadan önce yazın. Her kuralı iki kısa cümleyle açıklayamıyorsanız kullanıcılar yanlış anlayacaktır. Sert ama sakin bir dil kullanın: "Şüpheli etkinlikte kredileri bekletebiliriz" uzun bir tehdit listesi yerine daha net ve daha az düşmancadır.
Birincil bir tanımlayıcı seçin ve diğer her şeyi destekleyici delil olarak kabul edin. En temiz seçenekler yönlendirme bağlantı token'ı (paylaşması kolay), kısa kod (yazması kolay) ve belirli bir e-postaya gönderilen davettir (doğrudan davetler için en iyi). Birini gerçek kaynak olarak seçin ki atıf öngörülebilir olsun.
Bu tanımlayıcıyı mümkün olduğunca erken yakalayın ve yol boyunca taşıyın. Bir bağlantı token'ı genelde açılış sayfasında yakalanır, birinci taraf depolamada saklanır, sonra kayıt sırasında tekrar gönderilir. Mobil için mümkünse uygulama yükleme akışında geçirin, ama bazen kaybolacağını varsayın.
İş kurallarınıza uyan küçük bir olay seti takip edin. Hedefiniz "bu ücretli müşteri oldu mu" ise (sadece "tıkladılar" değil), minimal bir set yeterlidir:
referral_click (token görüldü)account_signup (yeni kullanıcı oluşturuldu)account_verified (e-posta/telefon doğrulandı)first_paid_invoice (ilk başarılı ödeme)qualification_locked (dönüşüm kabul edildi ve artık değişmez)Cihaz değişimleri ve engellenen çerezler normaldir. Bunları garip takip yöntemleriyle değil, kayıt sırasında iddia adımı ekleyerek ele alın: kullanıcı bir token ile gelmişse, yeni hesaba ekleyin; gelmemişse onboarding sırasında bir kez kısa kod girilmesine izin verin. Her ikisi de varsa, birincil olarak en erken yakalananı kullanın ve diğerini ikincil delil olarak saklayın.
Son olarak, destek ekibinin bir dakikada okuyabileceği basit bir zaman çizelgesi tutun: yönlendiren, yönlendirilen hesap (bilindiğinde), mevcut durum ve son anlamlı olay ile zaman damgaları. Birisi "neden kredi almadım?" diye sorduğunda, "kayıt oldu ama ilk ücretli fatura hiç gerçekleşmedi" gibi gerçeklerle cevap verebilirsiniz, tahminde bulunmak yerine.
Yönlendirme programları genelde veri modeli belirsiz olduğunda bozulur. Destek "kimi kim yönlendirdi?" diye sorar. Faturalama "kredi zaten verildi mi?" diye sorar. Günlükleri kazmadan cevap veremiyorsanız model sıkılaşmalı.
Yönlendirme ilişkisini birinci sınıf kayıt olarak saklayın, tıklamalardan türetilmiş bir tahmin olarak değil.
Basit, hata ayıklaması kolay bir düzen şöyle görünür:
id, referrer_user_id, referred_user_id, created_at, source (invite link, coupon, manual), status, status_updated_atreferral_id, invite_code_id veya campaign_id, first_seen_ip_hash, first_seen_user_agent_hashworkspace_id, owner_user_id, created_atworkspace_id, user_id, role, joined_atReferrals tablosunu küçük tutun. Sonradan pişman olacağınız şeyleri (ham IP, tam user agent, isimler) saklamaktan kaçının veya yalnızca kısa ömürlü hash'ler halinde ve net bir saklama politikasıyla saklayın.
Durumları açık ve birbirini dışlayan hâle getirin: pending (kaydoldu, henüz uygun değil), qualified (kuralları sağladı), credited (kredi verildi), rejected (kontroller başarısız), reversed (iade/chargeback sonrası kredi geri alındı).
Önceliği bir kere belirleyin ve sonra bunu veritabanında uygulayın ki uygulama yanlışlıkla iki kez kredi veremesin. En azından:
referred_user_id)credited durumuna gelebilirreferral_id'yi saklayınEkipleri destekliyorsanız, yönlendirmenin kişisel kayda mı yoksa workspace oluşturulmasına mı bağlanacağını belirleyin. İkisini aynı anda yapmaya çalışmayın. İşe yarayan bir yaklaşım yönlendirmeyi kullanıcı hesabına bağlamak, uygunluk kontrollerinin ise o kullanıcının (veya workspace'in) ücretli abone olup olmadığına bakmasıdır.
Daha az fatura hatası ve daha az destek bileti istiyorsanız, bir bakiye alanı yerine bir defter kullanın. Bir bakiye sayısı üzerine yazılabilir, yuvarlanabilir veya iki kez güncellenebilir. Bir defter her zaman toplamlanabilen girişlerin geçmişidir.
Giriş türlerini sınırlı ve net tutun: earn (verme), spend (faturaya uygulama), expire, reversal (geri alma) ve manual adjustment (not ve onaylayan ile).
Her giriş mühendislerin ve desteğin okuyabileceği şekilde olmalı. Tutarlı alanlar saklayın: amount, credit type (krediler nakit değilse "USD" demeyin), reason text, source event (ör. referral_signup_qualified), source ID'leri (kullanıcı, yönlendirilen kullanıcı, abonelik veya fatura), zaman damgaları ve created_by (sistem veya admin).
Idempotency beklenenden daha önemlidir. Aynı webhook veya arka plan işi iki kez çalışabilir. Kaynak olay başına benzersiz bir idempotency anahtarı gerektirin ki güvenli şekilde yeniden deneme yapabilesiniz ve çift kredi oluşmasın.
Kullanıcıya açıklanabilir yapın. Birisi "neden 20 kredi aldım?" diye sorduğunda hangi yönlendirmenin tetiklediğini, ne zaman kaydedildiğini, süresinin dolup dolmadığını ve sonra bir geri alma olup olmadığını gösterebilmelisiniz. Arkadaş bir yükseltme yaparsa, o yükseltme olayına bağlı bir earn girişi eklenir. Ödeme iade edilirse, iade olayına bağlı bir reversal girisi yayınlanır.
Çoğu insan dürüsttur; birkaç kişi kolay hileler deneyecektir. Amaç kolay suistimalleri durdurmak, kuralları açık tutmak ve aynı Wi-Fi ağını veya aile kartını paylaşan gerçek müşterileri engellememektir.
Referrer ile referred hesabın aynı kişi olduğu açık olduğunda kredi vermeyin: aynı user ID, aynı doğrulanmış e-posta veya aynı ödeme yöntemi parmak izi gibi. E-posta alanı kuralları yardımcı olabilir, ancak dar tutun—tüm şirket domain'lerini engellemek meşru ekipleri zarar verebilir.
Sonra döngüler ve toplu kayıtlar için hafif algılama ekleyin. Birinci günde mükemmel bir dolandırıcılık skorlamasına gerek yok. Güçlü birkaç sinyal çoğu suistimali yakalar: kısa sürede aynı cihazdan çok sayıda kayıt, dakikalar içinde aynı IP aralısından tekrar kullanımlar, aynı kartın birden çok "yeni" hesapta kullanılması, e-postaları doğrulamayan çok sayıda hesap veya krediler uygulandıktan sonra hızlı iptal ve yeniden abone olma örüntüleri.
Krediler kullanılmadan önce nitelendirici bir eylem gerektirin (örneğin: doğrulanmış e-posta artı ücretli fatura). Bu, botları ve ücretsiz katman churn'ünü ödül üretmekten alıkoyar.
Yönlendirme bağlantıları ve çözümlemeler etrafında hız sınırlamaları ve bekletmeler ekleyin, ama yalnızca gerektiğinde sessizce. Bir bağlantı bir saatte aynı ağdan 20 kez kullanıldıysa ödülleri duraklatın ve işaretleyin.
Müdahale ettiğinizde deneyimi sakin tutun. Kredileri ödeme doğrulanana kadar beklemede gösterin, ödüller geciktiğinde basit bir sebep gösterin (suçlama yerine), destek için açık bir yol sunun ve uç vakaları otomatik yasak yerine manuel incelemeye yönlendirin.
Örnek: bir startup ekibi tek bir ofis IP'si paylaşır. Üç iş arkadaşı aynı gün aynı yönlendirmeyle kaydolursa, doğrulama + ücretli fatura + temel bir soğuma süresi ile faturalar ödendikten sonra yine kredi kazanırlar; bot benzeri patlamalar ise incelemeye alınır.
Yönlendirme programları ödeme hareket etmediğinde basit hissedilir: bir iade, chargeback, void edilmiş fatura veya hesabın sahibi değiştiğinde işler karışır. Bu durumları baştan tasarlarsanız, kızgın kullanıcılar ve uzun destek konuları önlenir.
Kredileri sadece bir kayıt olarak değil, ücretli bir sonuç temelinde kazanılan şeyler olarak ele alın. O zaman geri alma politikasını faturalama olaylarına bağlayın.
Destek ekibinin açıklayabileceği bir kural seti:
Kısmi iadeler ekipleri zorlar. Bir yaklaşım seçin ve tutarlı kalın: orantılı geri alma (iadeye oranla kredi geri alınır) veya tam geri alma (herhangi bir iade tüm krediyi geri alır). Orantılı daha adildir ama test etmesi daha zordur; tam geri alma daha basittir ama sert gelebilir.
Denemeden ücrete geçişler de açık olmalı. Yaygın bir yöntem kredileri deneme süresi boyunca beklemede tutmak, sonra ilk başarılı ücretli fatura doğrulanınca (opsiyonel kısa bir bekleme sonrası) kilitlemektir.
Kişiler e-posta değiştirir, hesap birleştirir veya kişisel kullanımdan ekip workspace'ine geçer. Neyin kişiyi takip edeceğine ve neyin ödeyen hesabı takip edeceğine karar verin. Eğer bir workspace abone ise, krediler genellikle workspace'e aittir, üyeden ayrılabilecek bir kişiye değil.
Hesap birleştirmelerini veya sahiplik transferlerini destekliyorsanız, geçmişi yeniden yazmak yerine bir ayarlama olayı kaydedin. Her geri alma veya manuel düzeltme destek dostu bir not içermeli: "Invoice 10482 üzerindeki chargeback" veya "Workspace sahipliği transferi, destek tarafından onaylandı" gibi. Koder.ai gibi kredilerin aboneliklere uygulandığı platformlarda bu notlar "kredilerim neden değişti?" sorusuna tek bakışta cevap verir.
En zor kısım yönlendirmeleri takip etmek değil. Kredilerin yenilemeler, yükseltmeler, düşürmeler ve vergiler arasında aynı şekilde davranmasını sağlamaktır.
Önce kredilerin nerede kullanılabileceğine karar verin. Bazı ekipler kredileri yalnızca sonraki yeni faturaya uygular. Diğerleri kredilerin herhangi bir açık (ödenmemiş) faturayı kapatmasına izin verir. Bir kural seçin ve kullanıcı arayüzünde gösterin ki sürpriz olmasın.
Sonra işlem sırasını kilitleyin. Öngörülebilir bir yaklaşım: abonelik ücretlerini hesapla (prorasyon dahil), indirimleri uygula, vergiyi hesapla, sonra kredileri en sonda uygula. Kredileri en sona uygulamak vergi mantığını tutarlı tutar ve kredilerin her bölgede vergilendirilebilir tutarı azaltıp azaltmadığı tartışmalarını azaltır. Yasal/vergi gereksinimleriniz farklı bir sıra gerektiriyorsa, bunu belgeleyin ve testler yazın.
Prorasyon faturalama hatalarının en sık görüldüğü yerdir. Birisi dönemin ortasında yükseltme yaparsa, bir prorasyon satırı (ücret veya kredi) oluşturun ve bunu herhangi bir diğer satır gibi ele alın. Sonra yönlendirme kredilerini bireysel satırlara değil fatura toplamına uygulayın.
Fatura kurallarını sıkı tutun:
Örnek: bir kullanıcı ay ortasında yükseltme yapar ve 12$ prorasyon ücreti oluşur. İndirimler ve vergi sonrası fatura toplamı 32$ olur. Eğer kullanıcının 50$ yönlendirme kredisi varsa 32$ uygulanır, fatura 0$ olur ve 18$ sonraki yenileme için kalır.
Yönlendirme programını küçük bir faturalama özelliği olarak ele alın, pazarlama aracı değil. Amaç sıkıcı tutarlılık: her kredi bir sebebe, zaman damgasına ve bir sonraki faturaya giden net bir yola sahip olmalı.
Bir dönüşüm olayı ve bir kredi kuralı seçin. Örneğin: davet edilen kullanıcı sadece ücretli abone olduğunda ve ilk ödemesi onaylandığında nitelikli sayılır.
MVP'yi uçtan uca bir akış etrafında inşa edin: kayıt sırasında bir referral token veya kod yakalayın, nitelendirmeyi ödeme başarılı olduğunda çalıştırın (kullanıcı kartı girdiğinde değil), benzersiz bir idempotency anahtarı ile bir defter girişi yazın ve kredileri tahmin edilebilir sırada bir sonraki faturaya uygulayın.
Gerçeğin kaynağını erken belirleyin. Ya faturalama sağlayıcınız gerçek kaynak olur ve uygulamanız onu yansıtacak, ya da dahili defteriniz gerçek kaynak olur ve faturalama sadece "bu faturaya X krediyi uygula" bilgisini alır. İkisini karıştırmak genelde "kredilerim kayboldu" türü taleplere yol açar.
Daha fazla yönlendirme kuralı eklemeden önce yönetici araçları ekleyin. Destek, kullanıcı, referral kodu ve fatura ile arama yapabilmeli, sonra şu zaman çizelgesini görmeli: davet, kayıt, nitelendirme, krediler verildi, krediler harcandı ve geri almalar. Manuel ayarlamalar ekleyin ve her zaman kısa bir not zorunlu kılın.
Sonra kullanıcı deneyimini ekleyin: bir yönlendirme sayfası, her davet için bir durum satırı (pending, qualified, credited) ve faturalarla eşleşen bir kredi geçmişi.
Son olarak izleme ekleyin: yönlendirmelerde ani artışlar, yüksek geri alma oranları (iadeler veya chargeback'ler) ve aynı cihaz veya ödeme yöntemi paylaşımı gibi olağandışı örüntüler için alarmlar. Bu, suistimal kontrollerini sıkı tutarken normal kullanıcıları cezalandırmamanıza yardımcı olur.
Örnek: biri Koder.ai yönlendirmesini ekibiyle paylaşırsa, krediler yalnızca ilk başarılı ücretli abonelik sonrası görünmeli ve bu krediler bir sonraki yenilemede otomatik olarak azaltmalı, elle kupon gibi değil.
Çoğu yönlendirme programı pazarlamada değil faturalamada başarısız olur. En hızlı şekilde bilet üreten şey kredilerin tahmin edilemez hissettirilmesidir: kullanıcılar neden aldıklarını, ne zaman uygulanacağını veya bir faturanın neden farklı olduğunu söyleyemez.
Yaygın tuzak kurallar netleşmeden önce inşa etmektir. Eğer "nitelikli yönlendirme" belirsizse (deneme başlatıldı, ilk ödeme, 30 gün tutulan ücretli plan), krediler vaka bazında görüşülüp iade yapılmaya başlanır ve destek yükü artar.
Başka bir sık hata tek değişken bir "kredi bakiyesi" alımıdır. Bu basit görünürken yeniden denemeler, iadeler, plan değişiklikleri veya manuel ayarlamalarla sayı sürüklenir ve nasıl oluştuğu açılamaz.
Idempotency genelde göz ardı edilir. Ödeme sağlayıcıları webhook'ları tekrar dener, işçiler işleri tekrarlar ve kullanıcılar çift tık yapar. "Kredi ver" eyleminiz idempotent değilse, çift kredi basılır ve sadece gelir tutarsızlığı ortaya çıktığında fark edilir.
Kredi matematiği de doğru olmayabilir hatta toplamlar doğru olsa bile. Kredileri vergiden önce uygulamak veya prorasyonu yok saymak, ödeme sisteminin beklediğiyle uyumsuz faturalar oluşturur. Bu, eşleşmeyen makbuzlar, başarısız ödemeler ve zor uzlaşmalar getirir.
Fraud kontrolleri çok katı da olabilir. IP, cihaz veya domain'e göre engelleme yapıp itiraz yolu tanımamak gerçek yönlendirmeleri (ev arkadaşları, iş arkadaşları, aynı ağdaki ekipler) durdurur ve büyümeyi sessizce engeller.
Dikkat edilmesi gereken beş kırmızı bayrak:
invite_id, conversion_id) sahip değil.Örnek: bir Koder.ai Pro kullanıcısı ay ortasında yükseltme yapar, yönlendirme kredisi kazanır, sonra düşürür. Eğer sisteminiz tek bir bakiye alanı kullanıyor ve kredileri prorasyondan önce uyguluyorsa, sonraki fatura yanlış görünebilir; toplam yakın olsa bile uzun destek konusu olur. Bir defter ve sabit uygulama sırası bunu engeller.
Yayınlamadan önce birkaç kontrol çalıştırın; bunlar çoğu fatura ve destek sorununu erken yakalar:
Örnek: Maya, Noah'ı davet eder. Noah Maya'nın davetinden kaydolur, deneme başlatır, sonra Pro'ya yükseltir ve 30$ öder. Sisteminiz o faturayı nitelikli sayar ve Maya için 10$ abonelik kredisi girişini oluşturur.
Maya'nın sonraki yenilemesinde, fatura ara toplamı 30$ olur. Faturalama adımı kullanılabilir kredilerinden en fazla 10$ uygular; fatura 30$ ara toplam, -10$ kredi ve 20$ borç gösterir. Maya'nın defterinde kazanma için bir (+10) ve harcama için bir (-10 invoice #1234'e uygulandı) girişi olur.
Eğer Noah daha sonra ilk ödemesi için iade isterse, sistem Maya'nın kazanmış olduğu krediyi geri alan bir reversal girişi ekler (veya eşdeğer bir borç kaydı). Eğer herhangi bir kredi zaten kullanıldıysa, sonraki fatura farkı tahsil eder; geçmişi yeniden yazmaz.
Kırmızı bayrakları önlemeden hızlı ilerlemek için iki sonraki adım:
Atıf, nitelendirme, defter girişleri, faturaya uygulama ve geri almaları içeren tam akışı kısa bir plan dokümanında prototipleyin.
Sandbox'ta sabit senaryoları test edin: denemeden ücrete geçiş, kredi kullanıldıktan sonra iade, ay ortası yükseltme ve düşürme, ve bir yönetici ayarlaması.
Hızlı ilerleyip fatura mantığını kaybetmek istemiyorsanız, Koder.ai Planning Mode, snapshot ve rollback özellikleriyle yönlendirme akışını yineleyip fatura matematiği tutarlı olana dek platform içinde denemenize yardımcı olabilir. Tüm süreci koder.ai içinde yapıp hazır olduğunuzda kodu dışa aktarabilirsiniz.
Yönlendirme kredileri, gelecekteki faturalarınızda ödemeniz gereken tutarı azaltır (veya abonelik süresini uzatır).
Onlar banka hesabına nakit aktarma, hediye kartı veya ileride ödenecek bir para sözü değildir. Mağaza kredisi gibi düşünebilirsiniz; faturalamaya yansır.
Yaygın bir varsayılan: yönlendirme, yönlendirilen kullanıcının ilk başarılı ödemesini tamamlamasının ardından geçerli sayılır (genellikle e-posta doğrulaması sonrası ve bazen kısa bir geçiş sürecinden sonra).
"Davet gönderildi" veya yalnızca "kaydoldular" gibi tetiklemelerden kaçının; bunlar kolayca suistimal edilebilir ve itirazlarda savunması zordur.
Birincil doğruluk kaynağı olarak genellikle yönlendirme bağlantı token'ı veya kısa kod kullanın.
En iyi uygulama:
Destek hızlı yanıt verebilsin diye açık, birbirini dışlayan durumlar kullanın:
pending: kayıt var, henüz uygun değilqualified: kurallar yerine getirildi (ör. ilk ücretli fatura)credited: kredi verildiTek bir "bakiye" alanı zaman içinde üzerine yazılabilir, tekrar edilebilir veya çarpıtılabilir ve denetlenmesi zorlaşır.
Bir defter, her zaman toplayabileceğiniz bir girişler listesidir:
Bu, faturalamayı açıklanabilir ve hataları bulunabilir kılar.
“Kredi verme” eylemini kaynak olay başına tekil bir idempotency anahtarıyla yaparak idempotent hale getirin (örneğin, ilk başarılı fatura ID'si).
Aynı webhook veya arka plan işi iki kez çalışırsa, ikinci çalışmada hiçbir şey yapmamalıdır; böylece çift kredi verilmez.
Basit, açıklanabilir engellerle başlayın:
Sonra hafif suistimal kontrolleri ekleyin:
Faturalama olaylarına bağlı açık bir geri alma politikası tanımlayın:
Kısmi iadeler için bir kural seçin ve ona sadık kalın: orantılı geri alma (daha adil, daha karmaşık) veya tam geri alma (daha basit, sert olabilir).
Önerilen sıralama:
Karışıklığı azaltacak kurallar:
Destek yaratmayacak en basit MVP:
Bunların ardından UI ve yönetici araçlarını ekleyin, sonra karmaşık ödül katmanlarına geçin.
rejected: kontrolleri geçemedi veya uygun değilreversed: iade/chargeback sonrası kredi geri alındıSon durum değişikliği için zaman damgası tutun.