BillingMeld: защо също е важно сървърът да потвърждава покупката, а не приложението

Покупката вътре в мобилното приложение обикновено изглежда проста за потребителя. Той натиска бутон, потвърждава плащането, получава достъп до функция или абонамент — и очаква всичко да работи автоматично.

За разработчика зад този бутон започва много по-сложен процес. Трябва да потвърди самата покупка, да вземе предвид удължавания, окончателни срокове на абонамента, връщания, отзиви за операции, смяна на устройство и разлики между магазини като Apple и Google.

Основният проблем възниква, когато сървърът започне да счита клиентското приложение за основен източник на истината.

Ако приложението каже: „Покупката е направена“, сървърът отваря достъп и продължава да базира решението си на тази информация. Но жизненият цикъл на покупката не свършва тук.

Абонаментът може да бъде удължен, автоматичното продължаване да бъде деактивирано, плащането да бъде върнато, а операцията — оттеглена от магазина.

Затова в BillingMeld покупката потвърждава не приложението, а сървърът.

Клиентът съобщава, но не решава

В архитектурата на BillingMeld мобилното приложение не е основен източник на информация за покупката.

Клиентът може да предаде данни за извършената операция, но това е само основание за проверка. Окончателното решение взема сървърната част на BillingMeld, която проверява информацията чрез инфраструктурата на Apple или Google.

Това е фундаментална разлика.

Приложението на телефона може да работи със стари данни, да не получи навреме нови промени или да предаде вече несъвместима с текущото състояние информация.

Освен това, клиентът не трябва да има възможност самостоятелно да решава дали потребителят има право на платен достъп.

BillingMeld проверява, например:

• дали съществува такава покупка;

• относно ли се отнася към конкретно приложение и продукт;

• дали действителният платен период все още е активен;

• дали е настъпило следващо удължаване;

• дали е деактивирано автоматичното продължаване;

• дали е направено връщане;

• дали операцията не е анулирана;

• дали не е изтекъл платеният срок.

Така съобщението от клиента става не доказателство за покупка, а повод да се провери нейното текущо състояние.

Единен източник на истина за сървърите

Свързаните услуги не трябва да реализират самостоятелно цялата интеграция с Apple и Google.

Те се обръщат към BillingMeld и получават вече нормализираното състояние на покупката.

Например: активен достъп, изтекъл платен период, потвърдено следващо удължаване, деактивирано автоматично удължаване, оттеглена покупка.

Това позволява ясно разделение на отговорностите.

Apple и Google са източниците на състоянието на операциите в магазините. BillingMeld проверява тези данни, ги привежда към общ модел и съхранява актуалното състояние. А крайните продукти взимат решение за достъп въз основа на статусa на BillingMeld.

За сървърните части на продуктите това означава единен договор вместо множествени независими интеграции.

Няма нужда във всеки сервис отделно да се реализират правила за App Store, отделно — за Google Play, и после да се опитва да се хомогенизират различните формати, събития и статуси към една обща логика.

Защо клиентът не може да се доверява напълно

Клиентското приложение работи на устройството на потребителя.

Може да бъде затворено, рестартирано, възстановено от резервно копие, обновено по-късно или стартирано на друго устройство. То може да работи с остарели данни или да не получи събитие, случило се след първоначалната покупка.

Дори и без намеса на потребителя, това прави клиента лош източник за окончателното състояние на абонамента.

Например, потребителят е направил абонамент и е получил достъп. По-късно е направено връщане или магазинът е оттеглил операцията.

Ако сървърът знае само за първоначалното съобщение от клиента, той ще счита покупката за валидна.

Друг сценарий: потребителят може да деактивира автоматичното удължаване. В този случай, платеният период все още трябва да е активен до датата на изтичане.

Ако системата оперира само със прости статуси като „абонаментът е наличен / няма“, ще започне да затваря достъпа твърде рано или да оставя достъп, след като право на ползване вече е изтекло.

BillingMeld е построен около друга логика: клиентът не потвърждава собствените си права. Той съобщава за събитието, а сървърът определя действителното състояние на покупката.

Покупката — това не е едно събитие

Една от основните грешки в билнг архитектурата е да се приема, че покупката е едно събитие.

Фактически тя има жизнен цикъл.

Първо се появява операция. След това тя се потвърждава от магазина. За абонамент започва платеният период. По-късно може да се случи ново удължаване.

Потребителят може да деактивира автоматичното удължаване, но да продължава да ползва абонамента до края на вече платения период.

Плащането при следващо удължаване може да не бъде успешно.

Може да има връщане.

В някои случаи покупката може да бъде оттеглена.

Затова, една единствена покупка с „бил съществувала някога“ е недостатъчна.

Сървърът трябва да знае какво точно става в момента.

Оттеглянето на покупката не остава незабелязано

Особено ясно това се вижда при връщания и отзовавания на операции.

Първоначалната покупка може да е била напълно коректна. Потребителят действително е платил и получил достъп.

Но по-късно състоянието на операцията е променено.

Когато BillingMeld получи информация за тази промяна, той обновява статуса на покупката си и, ако е необходимо, я проверява допълнително чрез магазина.

След това свързаната услуга работи с новото състояние.

По този начин приложението вече не продължава да приема за сигурно, че преди няколко седмици или месеца клиентът е съобщил за успешна покупка.

Ако магазинът повече не отговаря, че правото все още е валидно, BillingMeld отразява това в състоянието си.

Отмяната на абонамент и изтичането на достъп — не е едно и също

Тук има важно разграничение.

Ако потребителят е деактивирал автоматичното продължаване, това обикновено не означава, че достъпът трябва да бъде прекратен незабавно.

Текущият платен период може да продължава да действа.

Така, BillingMeld трябва да запази информация, че автоматичното удължаване е деактивирано, но и да разбере датата на край на вече платения период.

И само след нейното изтичане, достъпът престава да бъде активен, ако не е потвърдено ново удължаване.

Това е един пример защо с просто булево subscription = 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.