Omnichannel Yetkilendirme Senkronizasyonu: Platformlar Arası Abonelik Erişimi
EventBridge, webhook ve idempotent işleme kullanarak web, iOS ve Android genelinde abonelik erişimini tutarlı tutan güvenilir bir yetkilendirme senkronizasyon katmanı nasıl oluşturulur.
Özet
Bir kullanıcı web sitenizden Stripe ile abone oluyor. Beş dakika sonra iOS uygulamanızı açıyor ve kilitli bir ekran görüyor. Bu, omnichannel yetkilendirme problemi -- ve birden fazla platformda abonelik satan her ürünü etkiliyor. Bu yazı, web, iOS ve Android genelinde erişimi tutarlı tutan bir yetkilendirme senkronizasyon katmanının nasıl tasarlanacağını kapsıyor. Farklı ödeme sağlayıcılarından gelen olayları normalleştirmeyi, idempotent webhook handler'lar oluşturmayı, olay tabanlı işleme için EventBridge kullanmayı ve platformlar arası abonelikleri zorlaştıran uç durumları ele almayı öğreneceksiniz.
Platformlar Arası Yetkilendirme Problemi
Ürününüz birden fazla kaynaktan ödeme kabul ettiğinde -- web için Stripe, iOS için Apple App Store, Android için Google Play -- her platform kendi formatında, kendi hızında ve kendi yaşam döngüsü modeliyle abonelik olayları gönderir.
Zorluk bu olayları almak değil. Zorluk, bunları tek ve tutarlı bir cevaba dönüştürmek: "Bu kullanıcı şu anda neye erişebilir?"
Her ödeme sağlayıcısının benzer kavramlar için farklı olay adları var. Apple buna DID_RENEW diyor. Stripe invoice.payment_succeeded diyor. Google SUBSCRIPTION_RENEWED diyor. Apple'dan bir yenileme olayı dakikalar sonra gelebilirken, Stripe neredeyse anında tetikleniyor.
Yetkilendirme katmanı olmadan, uygulama kodunuz her yere dağılmış platforma özgü kontrollerle doluyor. Bu yaklaşım, dördüncü bir ödeme kaynağı eklediğinizde veya abonelik katmanlarınızı değiştirdiğinizde bozuluyor.
Yetkilendirme Katmanı Tasarımı
Yetkilendirme katmanı, ödeme sağlayıcılarınız ile uygulama mantığınız arasında yer alır. Tek bir soruyu yanıtlar: verilen bir kullanıcı ID'si için, hangi özellikler ve erişim seviyeleri şu anda aktif?
Doğruluk Kaynağı Prensibi
Yetkilendirme deposu -- ödeme sağlayıcısı değil -- erişim kararları için doğruluk kaynağıdır. Ödeme sağlayıcıları faturalama durumu için doğruluk kaynağıdır, ancak yetkilendirme deponuz kullanıcının ne yapabileceğinin doğruluk kaynağıdır.
Bu ayrım önemli. Bir ödeme sağlayıcısı, kullanıcı hala erişim sahibiyken bir aboneliği "past_due" olarak raporlayabilir. Yetkilendirme katmanınız bu kuralları tanımlar, sağlayıcı değil.
Yetkilendirme Tablo Tasarımı
Yetkilendirmeler basit boolean değildir. Bir abonelik aktif, ödemesiz kullanım döneminde, duraklatılmış veya faturalama yeniden denemesinde olabilir -- ve her durum farklı erişim seviyelerine karşılık gelir.
source alanı hangi platformun bu yetkilendirmeyi oluşturduğunu takip eder. Çakışmaları ele alırken bu kritik hale gelir -- aynı kullanıcı hem Apple hem de Stripe'dan abone olduğunda, hangi yetkilendirmenin öncelikli olduğunu bilmeniz gerekir.
Özellik Eşleme
Abonelik planlarını plan adlarına güvenmek yerine somut özelliklere eşleyin. Bu, erişim mantığınızı fiyatlandırma yapınızdan ayırır.
Erişim kontrolü yaparken plan adları yerine özellikleri sorgulayın:
Platformlar Arası Senkronizasyon Stratejileri
Client'ları yetkilendirme deponuzla senkronize tutmak için üç yaklaşım var.
Polling
Client periyodik olarak yetkilendirme API'nizi çağırır. Uygulaması basit, ancak gecikme ekler -- bir kullanıcı erişim güncellemesini görmeden önce polling aralığı kadar bekleyebilir.
En uygun: gerçek zamanlı erişim güncellemelerinin kritik olmadığı uygulamalar. Tipik polling aralığı: aktif oturumlar için 30-60 saniye, arka plan için 5 dakika.
Push (WebSocket / Push Notification)
Sunucu, bağlı client'lara WebSocket veya mobil push notification ile yetkilendirme değişikliklerini iletir. Neredeyse anında güncelleme sağlar ancak altyapı karmaşıklığı ekler.
En uygun: anlık erişim değişikliklerinin önemli olduğu uygulamalar (işbirliği araçları, streaming servisleri).
Hibrit (Önerilen)
Sunucu tarafı webhook işlemeyi client tarafı akıllı polling ile birleştirin. Sunucu webhook'ları işler ve yetkilendirme deposunu hemen günceller. Client'lar düzenli aralıklarla poll yapar, ancak belirli tetikleyicilerde de yeniler.
Zorunlu yenileme için anahtar tetikleyiciler:
- Uygulama ön plana döndüğünde
- Kullanıcı bir satın alma akışını tamamladığında
- Abonelik değişiklikleri hakkında push notification alındığında
- Kullanıcı premium bir özelliğe gittiğinde
Webhook Güvenilirliği
Webhook'lar sunucu tarafı yetkilendirme güncellemelerinin omurgasıdır. Ancak webhook'lar doğası gereği güvenilmezdir -- sıra dışı gelebilir, tekrarlanabilir veya sessizce başarısız olabilir. Güvenilir bir webhook pipeline'ı dört kalıp gerektirir.
1. Önce Kuyruk İşleme
Webhook'u aldığınızda hemen HTTP 200 döndürün. Sonra asenkron olarak işleyin. Bu, zaman aşımlarını önler ve ödeme sağlayıcısının gereksiz yere yeniden denemesini engeller.
2. Olay Normalleştirme
Her sağlayıcı farklı payload gönderir. Daha fazla işlemden önce bunları ortak bir şemaya normalleştirin.
3. Idempotent İşleme
Webhook'lar en az bir kez teslim edilir. Aynı olay birden fazla kez gelebilir. Olay ID'sini DynamoDB koşullu yazma ile idempotency anahtarı olarak kullanın.
Anahtar kavrayış: hem Powertools idempotency (Lambda seviyesinde tekrar engelleme) hem de zaman damgası karşılaştırması (sıra dışı olayları ele alma) kullanın. Geç gelen bir olay, daha yeni bir durumun üzerine yazmamalı.
4. Ölü Mektup Kuyruğu (DLQ)
Tüm yeniden denemelerden sonra işlenemeyen olayların bir yere gitmesi gerekir. DLQ bunları inceleme ve yeniden oynatma için yakalar.
EventBridge Yetkilendirme Mimarisi
EventBridge, yetkilendirme senkronizasyonu için doğal bir uyum sağlar çünkü içerik tabanlı yönlendirme, yerleşik yeniden deneme ve doğal Lambda entegrasyonu sunar. İşte tam pipeline.
Olay Veriyolu ve Kurallar
Yetkilendirme olayları için özel bir olay veriyolu oluşturun. Olayları doğru işleme hedeflerine yönlendirmek için kurallar kullanın.
EventBridge, üstel geri çekilme ile yerleşik yeniden deneme sağlar -- 24 saat boyunca 185 yeniden denemeye kadar. DLQ ile birlikte, bu size birden fazla başarısızlık koruma katmanı verir.
Çoklu Platform Çakışmalarını Ele Alma
En zorlu uç durum: bir kullanıcı hem iOS'ta (Apple üzerinden) hem de web'de (Stripe üzerinden) premium planınıza abone oluyor. Şimdi farklı kaynaklardan aynı özellik seti için iki aktif yetkilendirmeniz var.
Çakışma Çözüm Stratejisi
Bir platform öncelik hiyerarşisi tanımlayın. Çakışmalar ortaya çıktığında, daha yüksek öncelikli kaynak erişim kararlarında kazanır, ancak her iki yetkilendirme de takip edilmeye devam eder.
Warning: Düşük öncelikli aboneliği otomatik olarak iptal etmeyin. Kullanıcıyı yinelenen abonelikleri olduğu konusunda bilgilendirin ve hangisini tutacaklarını kendileri seçsin. Otomatik iptal, destek talepleri ve ücret iadelerine neden olur.
Ödemesiz Kullanım Dönemi Farklılıkları
Her platform ödemesiz kullanım dönemlerini farklı ele alır:
- Apple: Yapılandırılabilir faturalama ödemesiz kullanım dönemi 3, 16 veya 28 gün (haftalık abonelikler için 6 gün), ardından Apple'ın ödeme tahsil etmeye çalıştığı 60 günlük faturalama yeniden deneme penceresi
- Google: Yapılandırılabilir ödemesiz kullanım dönemi (7 veya 30 güne kadar), ardından 60 gün eksi ödemesiz kullanım dönemi süresi olarak hesaplanan hesap askıya alma dönemi
- Stripe: Yapılandırılabilir dunning davranışı ile Smart Retries üzerinden yapılandırılabilir yeniden deneme planı
Yetkilendirme katmanınızın bu platforma özgü durumları kendi ödemesiz kullanım dönemi mantığınıza eşlemesi gerekir. En güvenli yaklaşım: herhangi bir aktif ödemesiz kullanım döneminde erişimi sürdürün ve tüm yeniden deneme pencereleri kapandıktan sonra yetkilendirmenin süresinin dolmasına izin verin.
Uzlaştırma
Idempotent işleme ve DLQ'larla bile sapma olur. Zamanlanmış bir uzlaştırma görevi, yetkilendirme deponuzu her ödeme sağlayıcısının abonelik API'si ile karşılaştırır ve tutarsızlıkları düzeltir.
Sapmayı yakalamak için yeterince sık çalıştırın, ancak sağlayıcı API hız sınırlarına takılmayacak kadar seyrek. Çoğu ürün için her 4-6 saatte bir iyi çalışır. Uzlaştırma düzeltmelerini her zaman logla -- çok sayıda görüyorsanız, webhook pipeline'ınızda bir boşluk var.
Temel Çıkarımlar
-
Faturalama durumunu erişim durumundan ayırın. Ödeme sağlayıcıları faturalamaya sahiptir. Yetkilendirme deponuz erişime sahiptir. Bu ayrım, ödeme mantığına dokunmadan ödemesiz kullanım dönemlerini, çakışmaları ve promosyonları ele almanıza olanak tanır.
-
Olayları erken normalleştirin. Sağlayıcıya özgü webhook'ları giriş noktasında ortak bir şemaya dönüştürün. Sonraki her şey tek formatla çalışır.
-
En az bir kez teslim için oluşturun. Webhook'lar tekrarlanabilir. EventBridge yeniden dener. Bunu güvenli bir şekilde ele almak için idempotency anahtarları ve zaman damgası karşılaştırmaları kullanın.
-
İlk günden uzlaştırma ekleyin. Webhook pipeline'ları zamanla sapma gösterir. Periyodik bir uzlaştırma görevi, kullanıcılar fark etmeden sorunları yakalar.
-
Yinelenen abonelikleri asla otomatik iptal etmeyin. Bir kullanıcının birden fazla platformda aboneliği olduğunda, bilgilendirin ve kendilerinin karar vermesine izin verin. Yanlışlıkla yapılan iptallerin destek maliyeti, yinelenenler ile başa çıkmanın mühendislik maliyetini çok aşar.
Bir abonelik ürünü oluşturuyorsanız, yetkilendirme katmanı doğru yapılmaya değer ilk çapraz kesim sorunlarından biridir. Her platforma, her özellik kapısına ve her kullanıcı oturumuna dokunur. Burada temiz bir olay tabanlı mimariye yatırım yapmak, ürününüz büyüdükçe bileşik getiriler sağlar.
Bu mimariye beslenen ödeme sağlayıcı seçimi için bkz. Ödeme Sağlayıcıları ve Uyumluluk. Burada tüketilen Apple ve Google olaylarını üreten mobil makbuz doğrulaması için bkz. Mobil IAP ve Paywall Stratejileri. Bu yetkilendirme değişikliklerini tetikleyen abonelik yaşam döngüsü yönetimi için bkz. Abonelik Yaşam Döngüsü Yönetimi.
Kaynaklar
- AWS EventBridge Dokümantasyonu - EventBridge olay veriyolları, kurallar ve hedefler için resmi kılavuz
- AWS Lambda Powertools for TypeScript - Idempotency - DynamoDB kalıcılığı ile Lambda fonksiyonları için idempotency yardımcı aracı
- RevenueCat: Platformlar Arası Abonelikler - Platformlar arası abonelik zorluklarına mühendislik derinlemesine bakış
- RevenueCat: Yetkilendirme Dokümantasyonu - Abonelik uygulamaları için yetkilendirme kavramları ve erişim seviyeleri
- Hookdeck: Webhook Idempotency Uygulama - Webhook işlemeyi idempotent yapma kalıpları
- Hookdeck: Ölçekte Webhook'lar - Güvenilir webhook altyapısı üzerine prodüksiyon dersleri
- Stripe Webhook En İyi Uygulamaları - Webhook güvenilirliği ve güvenliği için resmi Stripe kılavuzu
- Apple App Store Server Notifications V2 - Apple abonelik yaşam döngüsü bildirim referansı
- Google Play Gerçek Zamanlı Geliştirici Bildirimleri - Google Play abonelik olay bildirim referansı
- AWS EventBridge Fiyatlandırma - Ücretsiz aynı hesap teslimi dahil fiyatlandırma detayları
- Qonversion: Platformlar Arası Abonelik Yönetimi Kılavuzu - iOS, Android ve web genelinde aboneleri yönetmek için pratik kılavuz