- Kimler için?
- Uygulama içi satın alma veya abonelik ekleyen mobil geliştiriciler.
- Başlamadan önce
- Mağaza test hesapları, ürün kimlikleri ve kullanıcı-işlem ilişki modeli.
1. Satın alma ile erişim hakkını ayırın
Mağaza işlemi bir ödeme yaşam döngüsünün parçasıdır; entitlement ise kullanıcının şu anda hangi özelliğe erişebildiğini söyler. Uygulama içindeki bir boolean alan tek başına güvenilir kayıt değildir. Backend’de mağaza, ürün, işlem kimliği, kullanıcı ilişkisi ve geçerlilik durumu tutun. Hassas doğrulama verisini loglara veya herkese açık veritabanı alanlarına koymayın.
2. İstemci verisini doğrulama için ipucu olarak kullanın
İstemcinin gönderdiği ürün veya tutarı doğru kabul etmeyin. İlgili mağazanın güncel sunucu doğrulama mekanizmasıyla işlem kimliğini, uygulama/ürün eşleşmesini ve durumunu kontrol edin. Yetkili mağaza anahtarları yalnızca sunucuda tutulmalıdır. İstemci başarısız yanıt alırsa aynı işlemi tekrar gönderebilir; doğrulanmış satın alma ikinci kez hak üretmemelidir.
3. Durum makinesi ve tekrar güvenliği kurun
Yenileme, iptal, faturalandırma sorunu, süre sonu ve iade aynı olay değildir. İptal gelecekte yenilemeyi durdurabilir; mevcut erişimin sona erme kuralını mağaza durumundan ve ürün politikasından türetin. Sırasız veya tekrar gelen bildirimler daha yeni durumu geri çevirmemelidir.
| Girdi | Backend kararı |
|---|---|
| İlk doğrulanan işlem | İşlemi kaydet, kullanıcıya ilişkilendir |
| Aynı işlem tekrar | Önceki sonucu döndür |
| Yeni durum bildirimi | Yetkili kaynaktan durumu doğrula |
| İade veya süre sonu | Entitlement politikasını uygula |
4. Webhook ve reconciliation birlikte çalışsın
Webhook’u doğrulayın, olay kimliğini kalıcı kayda yazın ve uzun işlemi kuyruğa alın. Bildirim kaçması ihtimaline karşı periyodik reconciliation tasarlayın; seçilmiş kayıtların mağaza durumuyla uyumunu kontrol edin. Premium erişim verisini bu işin sonucu güncellesin. Bildirim body’sinin tek başına sonsuza kadar doğru kalacağını varsaymayın.
5. Sandbox senaryolarını yayın kriteri yapın
Başarılı satın alma dışında aynı işlemin iki kez gelişi, başka hesaba bağlama denemesi, gecikmiş webhook, yenileme, iade ve offline dönüşü deneyin. Bir cihazdan yapılan satın almanın diğer cihazdaki görünümünü test edin. Hesap değişikliği ve satın almayı geri yükleme akışı ürün politikasıyla tutarlı olmalı. Mağaza komisyonları ve doğrulama/operasyon giderleri hosting fiyatına otomatik dahil değildir.
- Transaction kimliği için benzersizlik kuralı uygulayın.
- Webhook imzasını ve beklenen uygulama kimliğini doğrulayın.
- Entitlement değişimlerini denetlenebilir biçimde kaydedin.
- Kullanıcıya doğrulama bekliyor durumunu gösterin.
Uygulama özeti
- Mağaza işlemi ile entitlement’ı ayırın.
- İstemciye değil doğrulanmış mağaza durumuna güvenin.
- Tekrar, iade ve gecikme senaryolarını test edin.
Sık sorulan sorular
İptal edildiğinde erişim hemen kesilmeli mi?
Her zaman değil. Mevcut dönem ve mağaza durumu esas alınmalı; ürünün erişim politikası açık olmalıdır.
Webhook olması periyodik kontrolü gereksiz yapar mı?
Hayır. Gecikme veya kaçan bildirim için reconciliation yararlı bir tamamlayıcıdır.
Kaynaklar ve kapsam
Teknik kaynaklar aşağıda. Örnekler açıklama ve kendi ortamınızda uygulama içindir; gerçek müşteri ölçümü veya çalışan Uygulama Cloud servisi iddiası içermez. Sağlayıcı ayarlarını uygulamadan önce ilgili belgenin güncel sürümünü kontrol edin.
Kaynak kontrolü: