- Flowglad, webhook olmadan çalışan açık kaynak bir ödeme işleme platformudur ve geliştiricilerin faturalandırma ve ödeme özelliklerini minimum kodla entegre etmesine olanak tanıyan bir yapı sunar
- Stateless mimari sayesinde
subscriptions tablosu veya customer_id yönetimi olmadan, kendi kullanıcı ID’nizle ödeme durumunu sorgulayabilirsiniz
- Full-Stack SDK sunar; backend’de
flowgladServer.getBilling(), frontend’de ise useBilling() hook’u ile müşteri durumu gerçek zamanlı yansıtılır
- Test modunda fiyat modelini deneyebilir ve tek tıklamayla production’a yansıtabilir, uygulamayı yeniden deploy etmeden plan değişikliği yapabilirsiniz
- Ödeme entegrasyonunun karmaşıklığını ve maliyetini azaltarak geliştirici deneyimini (DX) iyileştirir ve farklı ödeme sağlayıcılarıyla bağlantıyı tek bir entegrasyona genişletecek temel sunar
Başlıca özellikler
- Stateless yapı sayesinde webhook, abonelik tablosu, müşteri ID’si ve environment variable yönetimi gerekmez
- Fiyat ve özellik eşlemesini manuel olarak yönetmeye gerek kalmadan bunu doğrudan Flowglad üstlenir
- Tek doğruluk kaynağı (Single Source of Truth) olarak müşterinin en güncel faturalandırma durumu, özellik erişim yetkileri ve kullanım kredileri sorgulanabilir
- Özelleştirilmiş ID tabanlı erişim desteğiyle mevcut kimlik doğrulama sisteminizdeki kullanıcı veya organizasyon ID’leriyle müşteri durumu sorgulanabilir
- Full-Stack SDK sağlar
- Backend’de
flowgladServer.getBilling() çağrılır
- React frontend’de
useBilling() hook’u ile ödeme durumu gerçek zamanlı yansıtılır
- Esnek fiyat modeli yönetimi
- Test modunda yeni planları deneyip tek tıklamayla production’a alabilirsiniz
- Uygulamayı yeniden deploy etmeden plan değişimi yapılabilir
Kurulum ve entegrasyon
- Proje türüne göre
@flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server paketlerini kurun
- Next.js entegrasyon örneği
- Kendi müşteri ID’nizi ileterek bir
FlowgladServer instance’ı oluşturun
- API route’larında
nextRouteHandler kullanarak Flowglad ile güvenli iletişim kurun
- Kök layout’a
FlowgladProvider ekleyerek frontend’de ödeme durumunun otomatik yüklenmesini sağlayın
- B2C için
user.id, B2B için organization.id veya team.id müşteri ID’si olarak kullanılır
- Flowglad, ayrı bir müşteri ID’si yönetimi ya da kimlik doğrulama sisteminde değişiklik gerektirmez
Frontend örneği
useBilling() hook’u ile özellik erişimi (checkFeatureAccess) ve kullanım (checkUsageBalance) kontrol edilir- Özellik erişimi kısıtlıysa yükseltme yönlendirme mesajı gösterilir
- Kullanım yetersizse
createCheckoutSession ile ödeme oturumu oluşturulur
Backend örneği
- Sunucu tarafında
flowglad(user.id).getBilling() ile özellik erişimi ve kullanım kontrol edilir
- Örnek:
fast_generations özelliğine erişim olup olmadığına göre işlem akışı dallandırılır
- Örnek:
chat_messages kullanım kredisi yetersizse hata oluşturulur
Başlarken
- Dashboard üzerinden şablon kullanarak bir fiyat modeli oluşturun
- Sunulan şablon türleri
- Kullanım limiti + abonelik hibriti (Cursor benzeri)
- Sınırsız kullanım (ChatGPT tüketici tipi)
- Katmanlı erişim + kullanım kredisi (Midjourney benzeri)
- Özellik kilitlemeli abonelik (Linear benzeri)
- Gerekirse şablon kullanmadan da doğrudan model oluşturabilirsiniz
Teknoloji yığını
- Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth tabanlıdır
Proje hedefi
- Son 15 yılda geliştirme yığını çeşitlenmiş olsa da ödeme alanında neredeyse hiç yenilik olmadı
- Çoğu ödeme hizmetinde hesap kurulumu için bile satış ekibiyle görüşmek gerekir ve self-service ödeme seçenekleri yetersizdir
- Bunun sonucu olarak ödemeye dair geliştirici deneyimi (DX) ve maliyet iyileştirmeleri durağan kaldı
- Flowglad, ödeme entegrasyonu ve bakım süresini en aza indirmeyi, tek bir entegrasyonla birden fazla ödeme sağlayıcısını kullanmayı hedefler
- Yapay zekanın yaygınlaşmasıyla daha karmaşık hale gelen startup faturalandırma ortamında geliştirici dostu bir ödeme katmanı kurmayı amaçlar
1 yorum
Hacker News görüşleri
Bunun neden A) ‘payment processor’ olarak adlandırıldığını pek anlamıyorum
Aslında ödemeyi doğrudan işlemiyorken böyle denmesi tuhaf geliyor
Bir de B) ‘open source’ deniyor ama her şeyin SaaS üzerinden çalıştığı ve verilerin de onların DB’sinde tutulduğu anlaşılıyor
Özellik kapıları, kullanım kredileri, ödeme şemaları gibi esnek bir sistem kurmaya çalıştıkları için derdi anlıyorum ama başlığın vaat ettiği kadar somut bir şey sunduğunu hissetmiyorum
Open source tarafında SaaS kısmı AGPLv3, geri kalanı ise MIT lisansı altında
‘processor’ ifadesini kullanmamızın sebebi, Stripe Connect üzerinden ödeme işlesek de bunun sadece bir faturalama SaaS’ı olmadığını, ödeme işleme tarafını da kapsadığını netleştirmek istememizdi
Örneğin biz de mağazayla birlikte chargeback sorununu dert ediyoruz. Sadece Stripe anahtarını kullanan bir SaaS’tan farklı olarak, bizim yapımızda chargeback Stripe’taki gibi bizim için de doğrudan bir mesele oluyor
Bu ürünün bazı şeyleri kolaylaştırdığı doğru ama gerçekten daha iyi olup olmadığından emin değilim
Müşterinin abonelik durumu gibi şeyleri her kontrol edişte Flowglad sunucusuna API isteği atmak gerekiyorsa tepki süresi düşebilir
Sık erişilen veriler cache’lenebilir ama o zaman da bu katmanın anlamı azalıyor
Stripe entegrasyonu zahmetli olsa da yerelde hiçbir şey saklamayacaksanız Stripe API’sini doğrudan kullanmak daha iyi olabilir diye düşünüyorum
Benim için DB’de cache’lenmiş durum tutmak çok daha rahattı — çünkü karmaşık sorguları da doğrudan çalıştırabiliyordum
Bu yapıda Flowglad’in ihtiyaç duyulan API’leri sunmasını ummak gerekiyor; aksi halde müşteri sayısı kadar API isteği atmanız gerekebilir
Mağaza tarafında daha fazla veri saklanabilmesini sağlarken, bizim rafine ettiğimiz veri modelinden ve SDK kullanılabilirliğinden yararlanmaya devam etmeyi planlıyoruz
Stripe API’sini doğrudan kullansanız bile price id, plan, feature, customer id eşlemesini kendiniz yönetmeniz gerekiyor; biz bu tekrar eden işleri ortadan kaldırmak istiyoruz
Stripe yazma ağırlıklı bir sistem ve gerçek zamanlı okuma katmanı olarak kullanılmasını önermiyor (Stripe rate limits belgesi)
Hedefimiz, Shopify’ın DTC markalarına sunduğuna benzer şekilde geliştiricilere birleşik ödeme + değer aktarımı deneyimi sunmak
Başta yanlış anlamıştım ama yapı şuymuş: SDK ve kod açık kaynak, fakat gerçek faturalama verileri Flowglad sunucularına gönderiliyor; yani veriye doğrudan sahip olamıyorsunuz gibi görünüyor
Beta çıkışı kutlarım!
Ben de benzer bir sorun yaşadığım için, Flowglad’e benzer DX’e sahip bir Stripe entegrasyon kütüphanesi yaptım (özellikleri daha az kapsamlı olsa da)
Bunu neden yaptığımı anlatan bir blog yazısı da var
Temel fark, nihai faturalama bilgisinin nerede tutulduğu — biz DB şeması ve webhook handler’ları birlikte veriyoruz, böylece kayıtlar yerel DB’ye yazılıyor
Belki faydalı olur diye, yaptığımız MIT açık kaynak kütüphaneyi de önereyim
Beta çıkışı kutlu olsun, etkileyici bir ürün; entegrasyonu değerlendiriyorum
Ama neden React bağımlılığı gerektiğini merak ediyorum
React olmadan istenen UI’ı kurmanın bir yolu yok muydu?
Biz Svelte tabanlıyız, bu yüzden böyle bir kütüphane için React’i içeri çekmek rahatsız edici
React ile başlamamızın sebebi, en iyi bildiğimiz alanın ve topluluğumuzun orada olmasıydı
React’e takılıp kalmış değiliz; Svelte ve Vue desteği de yakında eklenecek
Veri modeli ve akışlar oturduğunda SDK’yı diğer framework’lere port etmeyi planlıyoruz
React kullanıcı tabanı 10 ila 50 kat daha büyük, dolayısıyla bu tür rahatsızlıklardan kaçınmak zor
Ama React bir framework değil, component rendering layer; iyi kapsüllenmiş bir harici kütüphane ise Svelte içinde de sorunsuz kullanılabilir
Landing page tasarımı gerçekten çok güzel yapılmış
Olumsuz görünmek istemedim; sadece Stripe üzerine kurulmuş olmasına üzüldüm
Çünkü son 1 yılı faturalama motoru, veri modeli ve SDK geliştirmeye harcadık
webhook’ların popüler olmasının sebebi basit, güvenilir ve işe yarıyor olmaları
Ama bunu kullanınca kullanım miktarı, abonelik katmanı, iptal gibi şeyleri takip etmek için ayrı bir altyapı kurmanız gerekebilir
İdeal bir dünyada para hareket ettiğinde müşterinin erişebileceği özellikler de buna göre otomatik belirlenmelidir
Shopify gibi sistemler buna örnek — webhook var ama asıl entegrasyon noktası o değil
Ödeme webhook’ları aslında karmaşık domain modelleme problemini aşmak için geliştirilmiş hackvari bir çözümdü
Zaten GNU Taler diye bir proje var ve bunu gerçek uzmanlar yaptı
https://www.taler.net/en/
Gizlilik odaklı çevrimiçi ödeme, kayıtsız ödeme, dolandırıcılığı önleyen tasarım, kendi altyapınızda çalıştırabilme ve özgür yazılım olması öne çıkan özellikleri
Mağazanın banka hesabı tarafında bunun nasıl çalıştığını merak ediyorum
Bu repo dışında başka bir şeye ihtiyaç var mı?
Şu anda mağaza hesabı kurulumu Stripe Connect üzerinden yapılıyor
Stripe’ın mağaza ödemelerini desteklediği bir ülkede kayıtlı tüzel kişilikseniz hemen kullanabilirsiniz
Uzun vadede ödeme tarafına daha derin entegre olmayı planlıyoruz
Yapısal olarak diğer gateway servislerine benziyor ama aracı ücreti eklendiği için işlem başına maliyet daha yüksek olabilir
Stripe webhook event’lerinin 250’den fazla olduğu ve bunun karmaşık olduğu söylenmiş ama tüm event’leri dinlemek gerekmiyor
Örneğin
charge.succeeded,payment_intent.succeeded,customer.subscription.createdevent’lerini nasıl işleyeceğinizi ve tekrarları nasıl önleyeceğinizi düşünmelisinizStripe’ı düzgün entegre etmek için bu tür ayrıntılara hâkim olmak gerekiyor
10 yıl önce 20 dakikada entegre etmiştim, yakın zamanda ise bütün günümü aldı