BillingMeld: מדוע שרת צריך לאשר את הרכישה במקום היישום

הרכישה בתוך אפליקציה לנייד נראית בדרך כלל פשוטה רק למשתמש. הוא לוחץ על כפתור, מאשר תשלום, מקבל גישה לתכונה או למנוי — ומצפה שהכל יפעל אוטומטית בהמשך.

למפתח, מאחורי הלחצן הזה מתחיל תהליך הרבה יותר מורכב. יש לאשר את הרכישה עצמה, לעקוב אחר חידושים, סיומי מנויים, החזרות, שינויים במצב הפעולה, שינוי מכשיר והבדלים בין חנויות Apple ל-Google.

הבעיה העיקרית מתרחשת כאשר השרת מתחיל לסמוך על היישום כמקור ה-AI.

אם היישום אומר: "הרכישה בוצעה", השרת מפתח גישה וממשיך להתייחס למצב שנקבע פעם אחת. אך מחזור החיים של הרכישה לא מסתיים כאן.

מנוי יכול להתחדש, חידוש אוטומטי יכול להיות מושבת, התשלום יכול להתבצע חזרה, והפעולה עצמה יכולה להיות מבוטלת על ידי החנות.

זו הסיבה שב-BillingMeld הרכישה מאושרת לא על ידי היישום, אלא על ידי השרת.

הלקוח מדווח, אך לא מקבל החלטות

באדריכלות של BillingMeld, היישום הנייד אינו המקור המרכזי למידע על הרכישה.

הלקוח יכול להעביר את נתוני הפעולה שביצע, אך זו רק בסיס לבדיקה. ההחלטה הסופית מתקבלת על ידי החלק השרת של BillingMeld, שבודק את המידע דרך תשתית Apple או Google.

זה ההבדל המרכזי.

היישום בטלפון יכול לעבוד עם מצב ישן, לא לקבל שינויים בזמן או להעביר נתונים שכבר לא תואמים למצב הנוכחי של הרכישה.

כמו כן, הלקוח לא צריך להחליט בעצמו האם המשתמש זכאי לגישה בתשלום.

BillingMeld בודק למשל:

• האם אכן קיימת רכישה כזו;

• האם היא קשורה ליישום ומוצר ספציפי;

• האם התקופה בתשלום בתוקף כרגע;

• האם התבצע חידוש אחרון;

• האם חידוש אוטומטי מושבת;

• האם בוצע החזר;

• האם הפעולה בוטלה;

• האם התקופה בתשלום עדיין בתוקף.

כך, ההודעה של הלקוח לא הופכת להוכחה לרכישה, אלא לסיבה לבדוק את מצבה האמיתי.

מקור האמת המרכזי לשרתים

השירותים המשולבים אינם צריכים ליישם באופן עצמאי את כל האינטגרציות עם Apple ו-Google בו זמנית.

הם פונים ל-BillingMeld ומקבלים מצב רכישה ממויין ואחיד.

לדוגמה: גישה פעילה, תקופת תשלום הסתיימה, חידוש נוסף אושר, חידוש אוטומטי מושבת או הרכישה מבוטלת.

זה מאפשר להבחין בבירור באחריות.

Apple ו-Google הם מקורות המצב של פעולת החנות עצמה. BillingMeld בודק את הנתונים, מביא אותם לתבנית משותפת ושומר על מצב עדכני. והמוצר הסופי מקבל החלטה על הגישה כבר על בסיס מצב ה-BillingMeld.

לעולמות הפיתוח, זה אומר הסכם יחיד במקום מספר אינטגרציות עצמאיות.

אין צורך בתמיכה נפרדת בכל שירות בחוקי App Store, בנפרד Google Play, ובלנסות לכנס פורמטים, אירועים ומדדים שונים ללוגיקה משותפת.

מדוע לא ניתן לסמוך באופן מלא על הלקוח

היישום במכשיר פעיל על מכשיר המשתמש.

אפשר לסגור אותו, להפעילו מחדש, לשחזר מגיבוי, לעדכן מאוחר יותר או להריץ על מכשיר אחר. הוא יכול לעבוד עם מצב ישן לזמן מה או לא לקבל כלל אירוע שקרה לאחר הרכישה הראשונית.

אפילו ללא התערבות של המשתמש, זה הופך את היישום למקור לא מהימן למצב הסופי של המנוי.

לדוגמה, המשתמש רכש מנוי וקיבל גישה. מאוחר יותר ייתכן והוחזר או שהחנות ביטלה את הפעולה.

אם השרת יודע רק על ההודעה ההתחלתית של הלקוח, הוא ימשיך לראות את הרכישה כפעילה.

במקרה אחר, המשתמש יכול לבטל חידוש אוטומטי. והמנוי בתשלום צריך להישאר פעיל עד לסוף תקופת התשלום שכבר שולמה.

אם המערכת פועלת רק עם מצב פשוט של "המנוי קיים / אין מנוי", היא עלולה לסגור את הגישה מוקדם מדי או להשאירה פעילה לאחר תום התקופה.

BillingMeld בנוי על לוגיקה שונה: הלקוח אינו מאשר את זכויותיו באופן עצמאי. הוא מספק אירוע, והשרת קובע את מצב הרכישה בפועל.

הרכישה — לא אירוע אחד

טעות עיקרית באדריכלות של תשלום היא לראות את הרכישה כאירוע חד-פעמי.

בהיא יש מחזור חיים משלה.

בהתחלה יש פעולה, שמאושרת על ידי החנות. לאחר מכן מתחיל התקופה בתשלום. אחר כך אפשר לחדש אותה שוב.

המשתמש יכול לבטל חידוש אוטומטי, אך להמשיך להשתמש במנוי עד לסיום התקופה בתשלום שכבר שולם.

התשלום יכול לא לעבור בחידוש הבא.

ייתכן וייוערך החזר.

האפשרות שהפעלה תבוטל קיימת גם היא.

ולכן, המספיק רק שהוגדר "הייתה רכישה זו פעם" אינו מספיק.

השרת צריך להבין מה קורה איתה כרגע.

ביטול הרכישה אינו נעלם מעיני השרת

הקלה על הצורך באדריכלות שרתים נראית היטב במקרים של החזרות וביטולי פעולות.

הרכישה ההתחלתית הייתה תקינה לחלוטין. המשתמש באמת שילם וקיבל גישה.

אך אחר כך מצב הפעולה השתנה.

אם BillingMeld מקבל מידע על שינוי, הוא מעדכן את מצב הרכישה ומשלים את הבדיקה מול החנות במידת הצורך.

לאחר מכן, השירות המשולב עובד עם המצב החדש.

באופן זה, היישום לא ממשיך לסמוך על ההודעה שהוגשה לפני שבועות או חודשים שהרכישה הייתה מוצלחת.

אם החנות אינה מחשיבה עוד את הזכויות כרגע בתוקף, BillingMeld משקף זאת במצבו.

ביטול מנוי וסיום גישה — לא אותו הדבר

יש הבדל חשוב כאן.

אם המשתמש ביטל חידוש אוטומטי, זה לא בהכרח אומר שהגישה צריכה להיסגר מידית.

התקופה בתשלום כבר בתוקף יכולה להמשיך לרוץ.

במקרה כזה, BillingMeld צריך לשמור את המידע על כיבוי חידוש עתידי, וגם להבין את תאריך סיום התקופה בתשלום שכבר שולמה.

רק לאחר סיומה, הגישה תחשב לבלתי חוקית אם לא בוצע חידוש מאושר חדש.

זה אחד מהסיבות שהגדרת "המנוי קיים = true" באופן פשוט אינה מספיקה לתחזוקת תשלום תקינה.

מצב המנוי תמיד קשור לזמן ולאירועים במחזור החיים שלו.

חידוש הוא גם חיפוש נפרד לבדיקה

המנוי לא מסתיים לאחר התשלום הראשון.

השרת צריך להבין האם חידוש אחר התרחש, והאם התקופה בתשלום המאושרת הבאה אושרה אוטומטית על ידי החנות.

BillingMeld עוקב אחר שינויים אלו ומעדכן את מצב המנוי.

אם חידוש אושר, הזכות לגישה ממשיכה.

אם לא התבצע תשלום נוסף או שהחנות אינה מאשרת את התקופה הבאה, המערכת לא תמשיך אוטומטית את הגישה על סמך ההערכה האישית שלה.

זה נראה טבעי למשתמש: הגישה קיימת כל עוד המנוי בתוקף.

זה אומר גם שהחברה לא צריכה ליישם בכל אפליקציה את לוגיקת החידוש בנפרד.

איך נראה תרחיש טיפוסי

המשתמש רושם מנוי באפליקציה ניידת.

היישום מקבל את פרטי הרכישה ומעביר את הנתונים ל-BillingMeld. אך הודעה זו עדיין לא משמשת כבסיס לסיווג הרכישה כמאושרת סופית.

BillingMeld מאשר את הפעולה דרך החנות הרלוונטית.

אם App Store או Google Play מאשר את הרכישה ומצבה תואם את חוקי המוצר, BillingMeld קובע את הזכאות הפעילה.

לאחר מכן, השירות המשולב מספק למשתמש את התכנים בתשלום.

המצב נשאר קבוע גם לאחר ההודעה ההתחלתית של הלקוח, וממשיך לתקוף אותו באופן עצמאי.

אם המנוי מתחדש, BillingMeld מתחשב בתקופה בתשלום החדשה.

אם המשתמש מבטל חידוש אוטומטי, התקופה הנוכחית תמשיך עד תומה.

אם תתרחש החזרה או ביטול הפעולה, מצב הרכישה ישתנה שוב.

בתוך מקרה זה, היישום לא מחזיק באמת עצמאית על הרכישה. הוא עובד על מצב שאושר ושמור ב-BillingMeld.

מה קורה כשמשתמש משנה מכשיר

המודל השרת-מבוסס מאוד שימושי כאשר המשתמש מחליף טלפון או מתקין מחדש את האפליקציה.

אין סיבה שהזכאות של הרכישה תתאפשר רק מכיוון שמכשיר מסוים כבר קבע הוכחה להצלחה.

ולהפך, התקנה מחדש של האפליקציה לא צריכה למחוק את הזכות המאושרת של המשתמש.

אם מצב הרכישה נמצא בצד השרת ומחובר לפעולת חנות מאושרת, מכשיר חדש יכול לקבל מצב עדכני דרך השרת.

זו סיבה נוספת למה לא לשמור את לוגיקת הגישה אך ורק בתוך הלקוח המוסרי.

מה זה נותן למפתחים

לקבוצה שמפתחת מספר אפליקציות ניידות או עובדת עם iOS ו-Android במקביל, תהליך התשלום במהרה הופך לתת-מערכת תשתיתית נפרדת.

צריך לקחת בחשבון:

• פורמטים שונים של נתונים מ-Apple ו-Google;

• אישור הרכישה הראשונית;

• חידושי המנויים;

• סיום תקופת תשלום בתוקף;

• השבתת חידוש אוטומטי;

• החזרות;

• ביטולים;

• התקנות מחדש של האפליקציה;

• החלפת מכשיר;

• שחזור רכישות;

• שינויים במצב שנעשו ללא מעורבות המשתמש.

BillingMeld מייצא לוגיקה זו לשכבה ייעודית ומובחנת.

השרתים של המוצר עובדים איתו תחת הסכם אחד ואינם צריכים לפרש לבד את כל המאפיינים של כל חנות בנפרד.

זה מפחית כפילות בקוד ומפחית סיכון לכך שיש כמה אפליקציות מבית אחד שמבינות באופן שונה את אותו תסריט תשלום.

העיקר אינו התשלום, אלא הזכאות המעודכנת

מה שמעניין אותי באדריכלות הזאת הוא המעבר מבדיקת רכישה בודדת לבקרה על מצבה המתמשך והעדכני.

התשלום ההתחלתי אינו משיב על השאלה המרכזית של המוצר:

האם למשתמש יש זכאות לתכונה בתשלום כרגע?

ייתכן שהייתה רכישה מוצלחת ותאריך סיום, או חידוש אוטומטי שבוטל אך התקופה בתשלום עדיין בתוקף, או חידוש מאושר שקרה, או ביטול של החנות, ובשורה התחתונה — הערכת מצב העדכנית של הזכאות היא המפתח.

בדיוק זאת מצב ה-BillingMeld שמספק לשאר השירותים.

BillingMeld כגבול בין חנויות למוצרים

כתוצאה מכך, נקבעת גבול ארכיטקטוני די ברור.

מצד אחד נמצאות חנויות כמו App Store ו-Google Play עם הפורמטים, האירועים, הכללים ומחזורי החיים של הרכישות שלהן.

ומהצד השני — יישומים ושירותים פנימיים הדרושים במקרים רבים לתשובה פשוטה הרבה יותר: אילו זכויות יש למשתמש כרגע.

ביניהם נמצא BillingMeld.

הוא מקבל את הנתונים מחנות, מאשר אותם, ממיר אותם לתבנית משלו ומספק תוצאה ממוינת ושקופה לתשתית שאר הכוללת.

זה מאפשר למוצרים לא לדעת את כל המאפיינים הפנימיים של כל פלטפורמת תשלום בנפרד.

מדוע זה חשוב למשתמש

המשתמש אינו צריך לדעת כלל על הארכיטקטורה הבילינג. אם הרכישה מאושרת ותקופת התשלום בתוקף, הגישה תהיה פעילה.

אם המשתמש עצר את חידוש אוטומטי, התקופה שכבר שולמה תמשיך לפעול כרגיל.

במקרה של חידוש חדש שהוכח, הגישה תמשיך ללא הפסקה.

אם החנות אישרה החזרה או ביטול, המערכת תשלב שינויים אלה במצב הזכאות.

בעת שינוי מכשיר או התקנה מחדש של האפליקציה, לא צריך שהמשתמש ידגיש כל פעם מחדש לכול חלקי התשתית שהרכישה אכן קיימת.

התוצאה היא כלל פשוט אחיד:

המשתמש מדווח על רכישה, החנות היא מקורה החיצוני של מצב הרכישה, BillingMeld מאשר ומטה את המצב הכולל, ושאר השירותים מקבלים החלטה על הגישה על סמך הנתונים המאושרים של BillingMeld.

זו הסיבה ש-BillingMeld איננו רק מודול תשלום נוסף.

זה שכבת ביטחון שרתית בין היישום הנייד, החנויות של Apple ו-Google ומוצרי הפרויקט, שמבקשים להבין בדיוק עכשיו אילו זכויות בתשלום שייכות למשתמש.

למידע נוסף על הפרויקט: billingmeld.de.