BillingMeld: satın alımın doğrulanması sunucu tarafından yapılmalı, uygulama değil

Mobil uygulama içi satın alma genellikle kullanıcı için basit görünür. Kullanıcı düğmeye basar, ödemeyi onaylar, fonksiyona veya aboneliğe erişim sağlar — ve bundan sonra her şeyin otomatik çalışacağını bekler.

Geliştirici için ise bu düğmenin arkasında çok daha karmaşık bir süreç başlar. Satın alma olayını doğrulamak, yenilemeleri, abonelik bitişlerini, iade ve işlem geri bildirimlerini, cihaz değişikliklerini ve Apple ile Google mağazaları arasındaki farklılıkları dikkate almak gerekir.

Ana sorun, sunucu müşterinin uygulamasını gerçek kaynağı kabul etmeye başladığında ortaya çıkar.

Eğer uygulama "Satın alma gerçekleştirildi" derse, sunucu erişim izni verir ve durumu bir kez aldığında ona göre hareket etmeye devam eder. Ancak satın alma yaşam döngüsü burada sona ermez.

Abonelik uzatılabilir, otomatik yenileme kapatılabilir, ödeme iade edilebilir ve işlem mağaza tarafından iptal edilebilir.

İşte bu nedenle BillingMeld’de satın alma, uygulama yerine sunucu tarafından doğrulanır.

Müşteri bildirse de, çözüm değil

BillingMeld mimarisinde, mobil uygulama satın alma hakkında ana bilgi kaynağı değildir.

Müşteri işlemi gerçekleştirdiğini bildirebilir, ancak bu sadece doğrulama için bir temel olur. Son kararı, Apple veya Google altyapısı üzerinden bilgiyi kontrol eden BillingMeld’in sunucu bölümü verir.

Bu temel farktır.

Telefon uygulaması eski durumu gösterebilir, yeni değişiklikleri zamanında alamayabilir veya satın alma sonrası gerçekleşen olaylara dair güncel olmayan veriler gönderebilir.

Ayrıca, müşteri, kullanıcının ücretli erişim hakkını kendisinin belirlemesine izin vermemelidir.

BillingMeld, örneğin şu konuları doğrular:

• Gerçekten böyle bir satın alma var mı;

• İlgili uygulama ve ürünle mi ilgili;

• Ödenmiş dönemi şu anda geçerli mi;

• Bir yenileme gerçekleşti mi;

• İleriye dönük otomatik yenileme kapandı mı;

• İade işlemi yapıldı mı;

• İşlem iptal edildi mi;

• Ödenmiş dönem bitmedi mi.

Bu nedenle, müşteri tarafından gelen bilgi artık satın alma kanıtı değil, onun durumunu gerçekten kontrol etmek için bir neden olur.

Sunucular için tek gerçek kaynağ

bağlı servisler, Apple ve Google ile tam entegrasyonları aynı anda gerçekleştirmek zorunda değildir.

BillingMeld’e başvururlar ve zaten normalleştirilmiş satın alma durumu alırlar.

Örneğin: erişim aktif, ödenmiş dönem bitmiş, yenileme onaylanmış, otomatik yenileme kapatılmış veya satın alma iptal edilmiş.

Bu, sorumluluğu net bir şekilde ayırmayı sağlar.

Apple ve Google, mağaza işleminin durum kaynağıdır. BillingMeld, bu verileri kontrol eder, ortak bir modele getirir ve güncel durumu saklar. Son ürün, erişim kararı alırken BillingMeld’in durumunu temel alır.

İş ürünleri sunucuları için bu, birçok bağımsız entegrasyon yerine ortak bir sözleşme anlamına gelir.

Her serviste App Store, Google Play kurallarını ayrı ayrı uygulamak yerine, farklı formatları, olayları ve durumları ortak mantığa uyarlamaya çalışmak gerekmez.

Neden müşteriye güvenmek değil,

müşteri uygulaması kullanıcı cihazında çalışır.

Kapatılabilir, yeniden başlatılabilir, yedekten geri yüklenebilir, sonra güncellenebilir veya başka bir cihazda çalıştırılabilir. Kısa süreliğine eski bilgilerle çalışabilir veya ilk satın alma sonrası gerçekleşen olayları alamayabilir.

Hatta kullanıcı müdahalesi olmadan, müşteri tamamen abonelik durumunun nihai kaynağı olamaz.

Örneğin, kullanıcı aboneyi yaptı ve erişim kazandı. Daha sonra iade veya işlem iptali gerçekleşebilir.

Eğer sunucu yalnızca ilk müşteri bildirimini bilir, satın alma aktif saymaya devam eder.

Başka durumda, kullanıcı otomatik yenilemeyi kapatabilir. Bu durumda da, zaten ödenmiş dönem geçerli olmaya devam eder.

Eğer sistem yalnızca "abone var/ yok" gibi basit bir durumu dikkate alıyorsa, erişimi çok erken kapatabilir veya süresi bitmiş olsa bile erişimi bırakabilir.

BillingMeld, başka bir mantık üzerine kuruludur: müşteri haklarını kendisi onaylamaz. O olay hakkında bilgi verir; sunucu, gerçek durumu belirler.

Satın alma bir olay değil, yaşam döngüsü

En temel hatalardan biri, satın alma olayını tek seferlik bir olay olarak görmektir.

Aslında, onun bir yaşam döngüsü vardır.

Önce işlem ortaya çıkar. Ardından mağaza onun doğrulanmasını sağlar. Abonelik başlar ve ücretli dönem devreye girer. Daha sonra bir yenileme olabilir.

Kullanıcı otomatik yenilemeyi kapatsa da, ödenmiş dönem sonuna kadar aboneliği kullanmaya devam edebilir.

Bir sonraki yenilemede ödeme başarısız olabilir.

Iade yapılabilir.

İşte bu yüzden, "Bu satın alma bir zamanlar varmış" tek başına yeterli değildir.

Sunucu, şu anda onun ne durumda olduğunu anlamalıdır.

İade veya iptal, fark yaratır

İptaller ve işlemler üzerindeki iade işlemleri, özellikle server mimarisinin önemini gösterir.

İlk satın alma tamamen doğru olabilir. Kullanıcı ürünü gerçekten ödemiş ve erişim almış olabilir.

Ancak daha sonra, işlemin durumu değişebilir.

BillingMeld, durumu değiştiğinde, durumu günceller ve gerekirse mağaza verilerini tekrar kontrol eder.

Bağlı servis artık yeni durumu kullanır.

Böylece, uygulama, müşterinin birkaç hafta veya ay önceki başarılı bildirimine sürekli güvenmek zorunda kalmaz.

Mağaza artık bu hakkı geçerli saymıyorsa, BillingMeld bunu durumu içinde gösterir.

Aboneliğin iptali ve erişimin sona ermesi — aynı değil

Burada önemli bir fark vardır.

Kullanıcı otomatik yenilemeyi kapattıysa, bu genellikle erişimin hemen kapanması anlamına gelmez.

Mevcut ödeme dönemi devam edebilir.

Bu durumda, BillingMeld, otomatik yenilemeyi kapattığını kaydeder, aynı zamanda ödenmiş dönemin bitiş tarihini de bilir.

Ve yalnızca onun sona ermesinden sonra, yeni bir onay alınmadıkça, erişim aktiviteyi kaybeder.

Bu, sürekli abonelik durumu için subscription = true gibi basit bir boole değeri yeterli olmadığını gösteren örneklerden biridir.

Abonelik durumu her zaman zaman ve olaylar ile ilişkilidir.

Yenileme de ayrı bir kontrol gerektirir

Abonelik ilk ödemeden sonra sona ermez.

Sunucu, bir yenileme olup olmadığını ve mağazanın yeni ödenmiş dönemi gerçekten onaylayıp onaylamadığını takip etmelidir.

BillingMeld, bu değişiklikleri izler ve abonelik durumunu günceller.

Eğer yenileme onaylanırsa, erişim devam eder.

Bir sonraki ödeme başarısızsa veya mağaza onaylamıyorsa, sistem, erişimi kendi varsayımlarıyla uzatmaz.

Bu durum, kullanıcının ödenmiş abonelik süresi gerçekten geçerli olduğu kadar erişimin devam etmesini sağlar.

Bu da geliştiricilere, aynı yenileme mantığını her uygulamada tekrar uygulama zorunluluğunu ortadan kaldırır.

Tipik senaryo nasıl işler

Kullanıcı, mobil uygulamada abonelik yapar.

Müşteri, satın alma bilgisi alır ve gerekli verileri BillingMeld’e iletir. Ama bu mesaj, satın alımın kesin olarak onaylandığını göstermez.

BillingMeld, ilgili mağaza üzerinden işlemi kontrol eder.

App Store veya Google Play satın almayı doğrular ve durumu ürün kurallarına uygunsa, aktif hakkı kaydeder.

Ardından, bağlı servis, kullanıcına ödenmiş imkanları sağlar.

Durum, ilk müşteri mesajından bağımsız olarak yaşamaya devam eder.

Abonelik uzatılırsa, yeni ödenmiş dönem dikkate alınır.

Kullanıcı otomatik yenilemeyi kapatırsa, mevcut dönem bitene kadar erişim devam eder.

İşlem iadesi veya iptali olursa, durum tekrar değişir.

Bu mimaride, uygulama kendi müstakil bir "gerçek" satın alma durumu tutmaz. Onlar, BillingMeld tarafından doğrulanıp saklanan durumu kullanır.

Cihaz değiştiğinde ne olur

Sunucu tabanlı model, özellikle kullanıcının telefon değiştirmesi veya uygulamayı yeniden yüklemesi durumunda faydalıdır.

Bir satın alma hakkı, yalnızca belirli bir örneğin başarılı bir işlem görmesiyle oluşmamalıdır.

Ve tam tersi, uygulama yeniden yüklenirse, kullanıcının doğrulanmış hakkı kaybolmamalıdır.

Eğer satın alma durumu sunucu tarafında ve mağaza işlemiyle ilişkiliyse, yeni cihaz yine de güncel durumu sunucu üzerinden alabilir.

Bu, erişim mantığını yalnızca mobil istemci içinde tutmama nedenlerinden biridir.

Geliştiriciler için ne sağlar?

Birden fazla mobil uygulama geliştiren veya iOS ve Android üzerinde çalışan ekipler için, billing çok kısa sürede bağımsız bir altyapı haline gelir.

Öncelikle, şu unsurları göz önünde bulundurmak gerekir:

• Apple ve Google’ın farklı veri formatları;

• İlk satın alma doğrulaması;

• Yenilemeler;

• Ödenmiş dönem bitişi;

• Otomatik yenilemenin kapanması;

• Iade işlemleri;

• İptal edilme;

• Uygulamanın yeniden kurulması;

• Cihaz değişimi;

• Satın alma geri yükleme;

• İşlem durumu değişiklikleri, kullanıcının katılımı olmadan gerçekleşebilir.

BillingMeld, bu mantığı ayrı bir katmanda tutar.

Ürün sunucuları, onunla tek bir sözleşmeyle çalışır ve her mağazanın özelliklerini kendi başına çözümlemek zorunda kalmaz.

Bu, kod tekrarlama sayısını azaltır ve aynı şirketin farklı uygulamalarının ödeme olaylarını farklı anlamasını önler.

İşin özü, kontrol değil, güncel hak

Bu mimaride beni en çok ilgilendiren, satın alma doğrulamasından, güncel durumu kontrol etmeye geçişti.

Ödeme ile ilgili tarihsel gerçek, temel soruyu yanıtlamaz:

kullanıcı şu anda ücretli fonksiyonları kullanmaya hakkına sahip mi?

İlk satın alma başarılı olabilir, ama dönem sonuna ulaşmış da olabilir.

Otomatik yenileme kapalı olabilir, ama ödenmiş dönem halen geçerli olabilir.

Doğrulanmış bir yenileme yapılmış olabilir.

Iade gerçekleşmiş olabilir.

Mağaza işlemi iptal edilebilir.

Bu nedenle, ana nesne doğrulama ve ilk müşterinin yanıtı değil, kullanıcının güncel hakkıdır ve doğrulanmış satın alma durumu temel alınarak hesaplanır.

İşte bu durumda, BillingMeld diğer servislere bu güncel hak bilgisini iletir.

Mağazalar ve ürünler arasındaki sınır olarak BillingMeld

Böylece oldukça net bir mimari sınır oluşur.

Bir yanda App Store ve Google Play, kendi formatları, olayları, kuralları ve yaşam döngüleriyle yer alır.

Diğer yanda ise, çoğu durumda ihtiyaç duyulan, kullanıcının şu an hangi haklara sahip olduğunu daha basit şekilde raporlayan uygulamalar ve dahili servisler vardır.

Arada BillingMeld bulunur.

Mağaza verilerini alır, doğrular, kendi modeline dönüştürür ve diğer altyapıya normalize edilmiş sonucu sağlar.

Bu sayede, ürünler, her mağazanın iç detaylarını bilmek zorunda kalmaz.

Kullanıcı için neden önemli

Kullanıcı açısından, doğru bir billing mimarisi idealiyle fark edilmemelidir.

Satın alma doğrulanmış ve ödenmiş dönem aktif ise, erişim aktif olmalıdır.

Kullanıcı otomatik yenilemeyi kapattıysa, hali hazırda ödenmiş dönem, erken sona ermeli değildir.

Yeni bir yenileme gerçekleşmişse, erişim devam etmelidir.

Mağaza, iade veya işlem iptal ettiyse, sistem hak değişikliğini doğru şekilde göstermelidir.

Telefon değişikliği veya uygulama yeniden yükleme durumunda, kullanıcının satın aldığını tekrar kanıtlaması gerekmemelidir.

Sonuç olarak, temel kural oldukça basittir:

Müşteri satın alımını bildirir, mağaza onun durumunun dış kaynağıdır, BillingMeld durumu doğrular ve normalize eder, diğer servisler ise doğrulanmış verilere dayanarak karar verir.

İşte bu yüzden BillingMeld sadece bir ödeme modülü değildir.

Mobil uygulama, Apple ve Google mağazaları ile ürünler arasında güvenilirlik için bir sunucu katmanı sağlar; kullanıcı hakkını şu anda net biçimde anlaması gereken servislerle iletişim kurar.

İlgili projeye detaylar: billingmeld.de.