Stripe e-posta entegrasyonlarını olaylar, faturalandırma verileri, kurulum ve hatırlatma uygunluğuna göre kıyaslayın: Brew, Sequenzy, Loops, Customer.io.
Bu karşılaştırmayı Brew yayımlıyor. Bağlantısını verdiğimiz ürün dokümantasyonunu 28 Eylül 2026’da inceledik; bu bir dokümantasyon karşılaştırması, her platformu bizzat test ettiğimizi iddia etmiyoruz. Güncel paket limitlerini firmanın fiyatlandırma sayfasından kontrol edin.
Bir müşterinin kartından yenileme ödemesi alınamıyor ve Stripe invoice.payment_failed olayını gönderiyor (fatura açık kalıyor). E-posta aracınız ödeme hatırlatma akışını başlatıyor. Müşteri ertesi sabah kartını güncelliyor, ama ikinci hatırlatma yine de o öğleden sonra gidiyor.
Pek çok e-posta platformu bir “Stripe entegrasyonu” sunduğunu belirtiyor. Ancak bu etiketin arkasındaki entegrasyonlar farklı biçimlerde çalışıyor. Bir araç ham Stripe webhooklarını dinleyip müşterinin planını ve abonelik durumunu senkronize ediyor. Bir diğeri faturalandırma hareketlerini kendi olay adlarına dönüştürüyor. Üçüncüsü ise webhookları kendiniz bağlamanız için bir rehber sunuyor.
Bir deneme süresi hatırlatmasının deneme durumunu kontrol edip edemeyeceğini ve kart yeniden çalıştığında başarısız ödeme takibinin durup durmayacağını bu farklar belirler. Bu rehber dört platformu bu noktalar üzerinden karşılaştırıyor.
saas.purchase ve saas.payment_failed gibi SaaS olaylarına dönüştürür.28 Eylül 2026’da her firmanın Stripe dokümantasyonunu kontrol ettik ve şunları karşılaştırdık:
| Araç | Bağlantı | Olaylar | Kişi kaydındaki faturalandırma verileri | Akışı durdurma |
|---|---|---|---|---|
| Brew | OAuth; webhooku Brew sizin için kaydeder | Checkout, müşteri, abonelik, fatura, teklif ve ödeme kategorilerinde 22 Stripe olayı | stripe_subscription_status, stripe_subscription_plan, stripe_plan_amount_cents, stripe_trial_end, stripe_renews_at, stripe_delinquent |
Senkronize edilen kişi alanlarına dayalı açık koşullar; ödenmemiş belirli bir fatura için uygulama tarafında kontroller |
| Sequenzy | OAuth | Stripe’tan türetilen SaaS yaşam döngüsü olayları | MRR, LTV ve trial, past-due, churned gibi etiketler |
Seri başına tek bir durdurma koşulu; örneğin saas.purchase olayı |
| Loops | Settings bölümünden “Connect to Stripe” | İtirazlar dâhil 20’den fazla Stripe olayı | E-posta adresi, ad ve soyad | İş akışı dallanmaları |
| Customer.io | Webhookla tetiklenen kampanyalar için bir rehber | Ona gönderdiğiniz olaylar | Sizin eşleştirdiğiniz veriler | Kampanya koşulları |
Brew, Stripe Apps üzerinden OAuth ile bağlanır; bu yüzden API anahtarlarınızı hiçbir zaman görmez. Ardından webhooku kendisi kaydeder ve 22 olay türüne abone olur:
checkout.session.completed ile birlikte gecikmeli ödemenin başarılı ya da başarısız sonuçlandığını bildiren olaylar.trial_will_end, silindi.payment_failed, yaklaşan fatura.charge.refunded, refund.created, payment_intent.payment_failed.Doğrulanan her olay, o olayı kullanan ve durumu Yayında olan tüm otomasyonları başlatır. Müşteri ve abonelik olayları ayrıca Stripe müşterisini, filtreleyebileceğiniz stripe_* alanlarıyla birlikte hedef kitlenize ekler ya da mevcut kaydı günceller. “Müşterileri Stripe’tan senkronize et” düğmesi, mevcut Stripe müşterilerini arka planda içe aktarır ve kesintiye uğrarsa kaldığı yerden devam edebilir.
E-postanın içinde amount, currency, invoiceNumber, previousPlan ve newPlan, failureMessage ve declineCode gibi birleştirme etiketlerini kullanabilirsiniz. Payload verileri Stripe nesne kimliklerini bilerek dışarıda bırakır; bu yüzden bunları birleştirme etiketi ya da filtre olarak kullanamazsınız.
Brew olayları alır; bir tahsilatı yeniden deneyemez, iade yapamaz ya da bir aboneliği değiştiremez. Bir Bekle adımından sonra contact.stripe_subscription_status koşulu, alanın Brew kişisindeki güncel değerini okur; olay alanları ise olayın ilk payload verisini korur. Kişi alanını okumak Stripe’ı sorgulamaz ve belirli bir faturanın ödendiğini kanıtlamaz. Sonraki bir ödeme hatırlatma olayını tetiklemeden önce o faturayı uygulamanızda kontrol edin. Kişi güncellemeleri ve yeni olaylar, mevcut çalıştırmaları otomatik olarak iptal etmez. Ayrıntılar için Brew dokümantasyonundaki otomasyon rehberine göz atın.
Brew e-postaları tasarlayıp gönderir de. Ödeme ve deneme süresi e-postaları markanızın tasarım sistemini kullanır ve doğrulanmış alan adınızdan gönderilir; bu yüzden ayrı bir şablon aracına ihtiyacınız olmaz.
Sequenzy’nin Stripe entegrasyonu OAuth ile bağlanır. İlk senkronizasyondan önce hangi ürünlerin dâhil edileceğini ve hangi meta verilerin aktarılacağını seçersiniz. Entegrasyon ardından faturalandırma hareketlerini satın alma, deneme süresinin başlaması ve bitmesi, iptal, müşteri kaybı, başarısız ödeme, plan yükseltme, plan düşürme ve iade gibi SaaS yaşam döngüsü olaylarına dönüştürür.
Kişiler, sayısal özellikler olarak MRR ve LTV değerlerini, ayrıca customer, trial, past-due ve churned gibi durum etiketlerini alır. Her serinin, her adımdan önce kontrol edilen tek bir durdurma koşulu vardır; böylece bir deneme süresi serisi, ek filtrelere gerek kalmadan saas.purchase olayıyla sona erebilir.
Sequenzy kişileri yalnızca e-posta adresine göre eşleştirir. Müşteri kaydı olmayan misafir Checkout oturumlarını gelir senkronizasyonunun dışında bırakır.
Sequenzy, abonelik yaşam döngüsü durumlarını kullanıma hazır hâlde isteyen ve Stripe’ın ham olay adlarına ihtiyaç duymayan SaaS ekiplerine uygundur.
Loops, Settings bölümündeki Connect to Stripe seçeneğiyle bağlanır. E-posta adresini, adı ve soyadı senkronize eder. E-posta adresi yeniyse bir kişi oluşturur; customer.deleted olayında kişileri abonelikten çıkarabilir ya da silebilir. Müşteri, abonelik, fatura, Checkout ve teklif olaylarının yanı sıra charge.dispute.created ve charge.dispute.closed dâhil yirmiden fazla olay, iş akışlarını başlatabilir. Loops, Nisan 2026’da daha fazla abonelik olayı ekledi.
Loops yalnızca e-posta adresi içeren olayları işler. Dokümantasyonu, senkronize edilen özellikler arasında plan ya da durum bilgisini saymıyor; bu yüzden faturalandırma durumuna dayalı koşullar için verinin başka bir kaynaktan gelmesi gerekir.
Customer.io, Stripe entegrasyonunu kendi kurmanız gereken bir yapı olarak belgeliyor. Stripe webhooklarını webhookla tetiklenen bir kampanyaya yönlendirir, kişiyi e-posta adresinden bulur ve kimliğini Stripe müşteri kimliği olarak ayarlarsınız. Bundan sonra istediğiniz faturalandırma verisini modelleyebilir ve e-posta, SMS ve anlık bildirim kanallarında kullanabilirsiniz. Diğer üç araçtan daha fazla kurulum gerektirir; buna karşılık veri modeli üzerinde daha fazla kontrol sağlar.
Stripe Billing, müşterilere kendisi de e-posta gönderebilir. Her başarısız kart ödemesinden sonra bir bildirim, ücretsiz deneme süresi bitmeden yedi gün önce bir hatırlatma, yenileme hatırlatmaları ve varsayılan kartın süresi dolmadan bir ay önce bir uyarı gönderebilir. Bu e-postalar, müşterinin ödeme yöntemini güncelleyebileceği bir sayfaya bağlantı verir.
Bunları açıp bir de invoice.payment_failed olayına dayalı bir Brew ya da Loops akışı kurarsanız müşteriler tek bir başarısız ödeme için iki e-posta alır. Her mesajı hangi sistemin göndereceğine karar verin. Olası bir iş bölümü şöyle: ödeme yöntemini güncelleme bağlantısını Stripe’a bırakın, açıklama ve takip e-postaları için e-posta platformunuzu kullanın. Kendi e-postalarınıza koyduğunuz bağlantının hâlâ geçerli olduğunu kontrol edin.
| İstediğiniz… | Göz atın |
|---|---|
| Ham Stripe olayları, senkronize edilen faturalandırma alanları ve tek bir üründe tasarlanıp gönderilen e-postalar | Brew |
| SaaS yaşam döngüsü olayları ve yerleşik durdurma koşulları | Sequenzy |
| Geniş Stripe olay kapsamına sahip, sade bir SaaS e-posta platformu | Loops |
| Birden fazla kanalda veri modeli üzerinde tam kontrol | Customer.io |
Abonelikler için: customer.subscription.trial_will_end, invoice.payment_failed, invoice.paid, customer.subscription.updated ve customer.subscription.deleted. Stripe, trial_will_end olayını deneme süresi bitmeden üç gün önce ya da deneme süresi kısaltılırsa hemen gönderir.
Bu araçlar e-postaları gönderir. Ödemenin yeniden denenmesi ve kart güncellemeleri Stripe’ta gerçekleşir. Brew dokümantasyonuna göre Brew tahsilat oluşturamaz ve abonelikleri değiştiremez.
Pazarlama e-postaları için evet. Brew dokümantasyonunun Stripe bölümüne göre kişi verilerini senkronize etmek, bu kişilere e-posta gönderme izni vermez. Mevcut bir abonelikle ilgili makbuzlar ve ödeme bildirimleri ise farklı bir kategoridir. Ayrıntılar için işlemsel e-postalar yazımıza bakın.
Stripe test modunda değil: Brew canlı Stripe hesaplarını bağlar; test modu olayları kişileri senkronize etmez ve otomasyon başlatmaz. Otomasyonu taslak olarak tutun ve kontrolünüzdeki alıcılarla test edin. Loops dokümantasyonu ise test müşterileri oluşturmayı ya da Stripe CLI ile trigger komutunu kullanarak olay tetiklemeyi öneriyor.
Brew tarafının ayrıntıları için Stripe entegrasyon sayfasını okuyun, ardından bir akışı taslak olarak kurun ve yayımlamadan önce kontrolünüzdeki alıcılarla test edin.
