#Jedno nastavení, které rozhoduje, zda se prodej zaplatí jednou, dvakrát, nebo vůbec
Většina integrací affiliate programů obsahuje skryté nastavení, které zakladatelé často přepínají, aniž by si ho dvakrát přečetli. Přitom právě toto nastavení rozhoduje o tom, zda vám obnovení předplatného v hodnotě 9,99 $ zaplatí influencera jednou, dvakrát, nebo vůbec.
Každá aplikace s předplatným potřebuje důkaz, že k nákupu skutečně došlo, než za něj vyplatí provizi. Existují přesně dva způsoby, jak tento důkaz získat: požádat RevenueCat, aby vám událost předal, nebo se dotázat přímo Applu či Googlu. Obojí funguje. Ani jedno není „správnější“. Problém je v tom, že obě cesty se nakonec dotazují na stejný backend – takže pokud je spustíte na jeden nákup současně, nezískáte druhý názor, jen položíte stejnou otázku dvakrát a za obě odpovědi zaplatíte.
#Jak každá cesta skutečně potvrzuje, že někdo zaplatil
Cesta přes RevenueCat funguje jako relé. SDK vaší aplikace nastaví atribut předplatitele – značku (tag), jako je například referenční kód – ve chvíli, kdy si někdo aplikaci nainstaluje přes affiliate odkaz. RevenueCat tento atribut uloží k danému předplatiteli a ze strany SDK je zápis pouze jednosměrný a po nastavení neměnný, takže nikdo nemůže zpětně nenápadně přepsat, kdo má nárok na provizi. Při předplatném a každém jeho obnovení odešle RevenueCat na váš server webhook, který tento atribut obsahuje. Data o atribuci jsou součástí samotných událostí INITIAL_PURCHASE a RENEWAL.
Store-Direct relé obchází. Váš server volá přímo App Store Server API od Applu nebo službu Google Play a ptá se: proběhla tato transakce, je platná, je stále aktivní? Aktualizace Applu z roku 2025 přidala podepsaný objekt transakce a nové koncové body vytvořené specificky pro tento typ kontroly na straně serveru – bez zapojení zařízení nebo třetí strany.
Nejedná se o dva nezávislé zdroje pravdy. RevenueCat se dotazuje na naprosto stejný backend Applu nebo Googlu, na který byste se dotazovali vy sami. Je to obal (wrapper), nikoliv druhý kontrolní bod.
#Matematika provozování obou cest najednou
Níže uvedená čísla jsou ilustrativním modelem – nejde o reálná data o transakcích InfluTo – a slouží k vysvětlení mechaniky, nikoliv k reportování míry výskytu.
Instinkt provozovat obojí „pro jistotu“ je pochopitelný – redundance je obvykle dobrý inženýrský přístup. Zde je to ale špatně, protože neexistuje nic redundantního, co by se dalo kontrolovat: jedna transakce, jeden záznam v účetní knize na serverech Applu, dvoje dveře, které se na ni ptají.
Představte si předplatné za 9,99 $/měsíc s 20% provizí – tedy 2,00 $ za každé obnovení. Pokud jsou aktivní obě cesty, webhook RevenueCat při obnovení spustí proces a váš systém zaeviduje 2,00 $ jako zaplacené. O několik minut později proběhne kontrola Store-Direct proti Applu, uvidí stejné obnovení a – aniž by ji cokoliv upozornilo, že už bylo započítáno – zaeviduje dalších 2,00 $. Jeden prodej za 9,99 $, ale z pokladny odcházejí 4,00 $. Takto to dopadá u každého obnovení, které obě cesty zachytí, v každém cyklu, dokud si toho někdo nevšimne.
Nyní to otočme: aktivní je pouze Store-Direct, ale úloha nikdy neobdrží referenční kód, protože nebyl propojen s voláním App Store Server API – toto mapování musíte vytvořit explicitně, API Applu ho nativně nepřenáší. Obnovení proběhne. Apple ho potvrdí. Kontrolní volání proběhne úspěšně. Ale nic nespojuje transakci s affiliate partnerem, takže provize 2,00 $, která by měla existovat, nikdy nevznikne. Žádná chyba, žádná selhaná úloha, nic v logu, co by se dalo vyhledat. Jen influencer, který si po třech měsících všimne, že se předplatitel, kterého doporučil, nikdy neobjevil ve výpisu.
Pokud tento scénář aplikujete na desítky předplatitelů a několik fakturačních cyklů, rozdíl mezi dlužnou a vyplacenou částkou přestane být zanedbatelnou chybou – a to v obou směrech, přičemž příčina je stejná: dva systémy, nebo jen ten špatný, se dívají na data, která nebyla od začátku nijak nejednoznačná.
#Kde každá cesta selhává jinak
Ani jedna cesta není imunní vůči všem selháním – selhávají jen odlišně. Vědět, jakému selhání jste vystaveni, je důležitější než hledat „vítěze“.
Refundace. Webhooky RevenueCat jsou navrženy pro doručení „alespoň jednou“, takže událost refundace může teoreticky dorazit dvakrát – vaše logika pro zpětné odečtení (clawback) musí být idempotentní, jinak provizi, která byla vyplacena pouze jednou, odečtete dvakrát. Store-Direct takový výstřelek při doručení nemá, ale zase vám refundaci sám nepošle – musíte si změny stavu sami dotazovat (poll).
Konverze ze zkušební verze na placenou. RevenueCat tento proces modeluje jako jeden kontinuální životní cyklus. Store-Direct považuje každý stav za samostatné vyhledávání, které musíte sami pospojovat.
Rodinné sdílení a obnova nákupů (restore). Zde se projevuje síla identifikace na straně obchodu. Apple originalTransactionId i Google purchaseToken zůstávají při obnově nebo sdíleném nákupu stabilní – to je identifikátor, podle kterého se obě cesty nakonec řídí při deduplikaci, takže obnovený nákup není znovu přiřazen k novému referenčnímu kódu.
Migrace uprostřed kampaně. Přepnutí validačních cest za běhu bez čistého přechodu je způsob, jak vytvořit mezeru: nákupy provedené v přechodném období mohou skončit v obou systémech, nebo v žádném.
#Kdy vyhrává Store-Direct a kdy RevenueCat
Neexistuje univerzálně „lepší“ cesta – ta správná závisí na tom, co už ve svém stacku máte.
Zvolte cestu přes webhooky RevenueCat, pokud již RevenueCat používáte ke správě předplatného, nebo pokud prodáváte na iOS i Androidu a chcete mít jeden přehled o stavu předplatitelů namísto dvou samostatných integrací obchodů. Vyměňujete závislost na třetí straně za méně technické instalatérské práce.
Zvolte Store-Direct, pokud chcete mít v cestě mezi vaší aplikací a Applem či Googlem nulovou závislost na správci předplatného třetí strany – někteří zakladatelé to potřebují kvůli compliance, latenci nebo kontrole – nebo pokud RevenueCat vůbec nepoužíváte a přidání této služby čistě kvůli atribuci by znamenalo novou závislost bez jakéhokoliv dalšího přínosu.
| Vaše situace | Doporučená cesta |
|---|---|
| Již používáte RevenueCat pro předplatné | Webhook RevenueCat |
| iOS + Android, chcete jeden přehled předplatitelů | Webhook RevenueCat |
| Nechcete třetí stranu v cestě kontroly nákupů | Store-Direct |
| Nepoužíváte RevenueCat, jednoduchá aplikace na jedné platformě | Store-Direct |
#Jak se rozhodnout a neudělat chybu
Vyberte si jednu cestu. Ujistěte se, že druhá je zcela vypnutá – ne jen „nepoužívaná“, ale deaktivovaná. To je celé rozhodnutí a špatná volba stojí peníze v obou směrech.
Než to nasadíte: ověřte, že pouze jeden zdroj validace zapisuje události provizí do vaší účetní knihy, otestujte refundaci a obnovu (restore) proti zvolené cestě a zkontrolujte, zda atribuce doporučení přežije přechod ze zkušební verze na placenou, pokud vaše aplikace nabízí zkušební období. Poté pozorně sledujte svůj první skutečný výplatní cyklus – zdvojená nebo chybějící provize hned první den je ta nejlevnější chyba, na kterou můžete narazit.
Informace o tom, co se stane poté, co se do vaší účetní knihy dostane duplicitní nebo chybějící událost, najdete v článcích Stop Paying Influencers Twice on the Same Renewal a Pay Influencers by Revenue? One Purchase Could Pay Two. Pokud stavíte na platformě InfluTo, obě validační cesty jsou podporovány nativně – platforma vynucuje, aby byla aktivní vždy právě jedna, takže k tomuto typu chyby při nasazení dojít nemůže.
Mohu později přejít z RevenueCat na Store-Direct, aniž bych ztratil historii provizí?
Ano – záznamy o provizích, které již byly zaevidovány, zůstávají vázány na identifikátor transakce obchodu, který je vygeneroval, protože tento identifikátor (Apple originalTransactionId nebo Google purchaseToken) se při přepnutí validačních cest nemění. Důležité je pouze neprovozovat obě cesty současně během přechodného období.
Funguje validace servisního účtu Google Play stejně jako Apple App Store Server API?
Mechanismus je analogický – přihlašovací údaje server-server vám umožní dotazovat se na stav nákupu přímo u Googlu – ale identifikátory a podoba API se liší, takže tyto dvě cesty nejsou vzájemně zaměnitelné, přestože jejich architektonická role je identická.
Co se stane s nákupy, které už InfluTo sledovalo, pokud vypnu aktuálně aktivní validační cestu?
Již přiřazené a vyplacené provize nejsou zpětně ovlivněny. Vypnutí cesty pouze zastaví tok nových událostí z tohoto zdroje – a právě proto je nutné potvrdit, že náhradní cesta je plně funkční, než tu starou deaktivujete.