Ako IN_APP_NOTIFY funguje, keď sa vrátenie platby uskutočňuje prostredníctvom fakturácie v aplikácii Android? - Android, nákup v aplikácii, účtovanie v aplikácii, titánové moduly

Našu aplikáciu sme vyvinuli pomocou programu Titanium Studio a Appcelerator ponúka bezplatný modul pre Fakturácia v aplikácii, ktorá podporuje iba rozhranie API v2 (Viem, že by sme mali používať v3, ale sme indie skupina, takže 100 dolárov za modul, ktorý podporuje API v3, je zatiaľ nie).

Čítal som dokumentáciu na Pracovný postup fakturácie v aplikácii pre API v2, a zatiaľ logika nákupu funguje ako kúzlo.

To je dovtedy, kým sa nedostaneme k časti vrátenia peňazí. V našej aplikácii sme spravovali produkty a predplatné.

Podľa dokumentácie, keď sa vrátia peniaze, IN_APP_NOTIFY sa spustí udalosť, ktorá si vyžaduje, aby sme uskutočnili a getPurchaseInformation hovor. Pochybujeme, čo sa stane po tom, čo urobíme getPurchaseInformation hovor. Má a PURCHASE_STATE_CHANGED udalosť je spustená? Ak je, potom sa podpísané údaje s objednávkami vrátia aktualizované?

Povedzme napríklad, že používateľ Uriel kúpi spravovaný produkt A, potom Uriel požiada o vrátenie platby. To by spustilo udalosť IN_APP_NOTIFY a getPurchaseInformation hovor.

Aká udalosť sa spustí, aby som mohol aktualizovať aplikáciu a uzamknúť obsah, ktorý mal predtým používateľ k dispozícii? Will PURCHASE_STATE_CHANGED byť spustený? Ak je, potom sa podpísané údaje s informáciami o objednávkach vrátia prázdne? V mojom PURCHASE_STATE_CHANGED Potvrdzujem, či existujú objednávky, ak sa nenájdu žiadne, potom sa zablokuje všetok obsah.

Stručne povedané, je môj odhad správny alebo je postup vrátenia peňazí iný?

Pre porovnanie, tu sú moje PURCHASE_STATE_CHANGED funkcie:

function PURCHASE_STATE_CHANGED_EVENT(e)
{
Ti.API.info("PURCHASE STATE CHANGED CALLED");
Ti.API.info("Signature Verification Result:n" + VerificationString(e.result));
Ti.API.info("Signed Data:n" + e.signedData);
/*
* We receive an object that might look like this
* {
*  "nonce":-2458019374247073515,
*  "orders":[
*   {
*    "notificationId":"notificationId",
*    "orderId":"transactionId",
*    "packageName":"my.package",
*    "productId":"in_app_identifier",
*    "purchaseTime":1394062412214,
*    "purchaseState":0
*   }
*  ]
* }
*/

if (e.signedData != null) {
var response = JSON.parse(e.signedData);
/*
* We are not guaranteed to have any orders returned so
* we need to make sure that this one exists before using it.
*
* If there is no notificationId then there is no need to confirmNotifications().
* This happens when restoreTransactions() triggers a PURCHASE_STATE_CHANGED_EVENT.
*/
if(response.orders.length === 0)
{
Ti.API.info("nothing to restore");
setNoTransactionsToRestore();
return;
}
for(var i = 0; i < response.orders.length; i++)
{
if(typeof response.orders[i] !== "undefined")
{
Ti.API.info("set purchase flag");
setPurchaseFlag(response.orders[i].productId);
}
if (response.orders[i] && response.orders[i].notificationId)
{

Ti.API.info("confirming notification for order " + JSON.stringify(response.orders[i]));
var synchronousResponse = InAppBilling.confirmNotifications({
notificationIds: [response.orders[i].notificationId]
});
displaySynchronousResponseCodes(synchronousResponse);
}
}
}
else
{
Ti.API.info("signed data was null");
}
}

InAppBilling.addEventListener(InAppBilling.PURCHASE_STATE_CHANGED_EVENT, PURCHASE_STATE_CHANGED_EVENT);

a môj IN_APP_NOTIFY funkcie:

function NOTIFY_EVENT(e)
{
Ti.API.info("NOTIFY CALLED n" + "Notify Id:n" + e.notifyId);

var synchronousResponse = InAppBilling.getPurchaseInformation({
notificationIds: [e.notifyId]
});
displaySynchronousResponseCodes(synchronousResponse);
}
InAppBilling.addEventListener(InAppBilling.NOTIFY_EVENT, NOTIFY_EVENT);

odpovede:

Čítal som dokumentáciu, ktorá poskytuje viac podrobností o pracovnom postupe, najmä udalosť IN_APP_NOTIFY. Tu je to, čo som našiel:

Spracovanie refundácií a ďalších nevyžiadaných IN_APP_NOTIFY správ

Existujú dva prípady, kedy vaša žiadosť môžeprijímať IN_APP_NOTIFY vysielacie zámery, aj keď vaša aplikácia neposlala a Správa REQUEST_PURCHASE. Obrázok 5 zobrazuje postupnosť správ pre obidva tieto prípady. Typy žiadostí pre každú sendBillingRequest () metóda je uvedená tučne, zámery vysielania sú zobrazené kurzívou. Pre jasnosť, obrázok 5 nezobrazuje zámery vysielania RESPONSE_CODE ktoré sa zasielajú pri každej žiadosti.

Obrázok 5. Sekvencia správ o vrátení platby a iných nevyžiadaných správach IN_APP_NOTIFY správ.

V prvom prípade môže byť doručená vaša žiadosťIN_APP_NOTIFY vysielací zámer, keď má používateľ nainštalovanú vašu aplikáciu na dvoch (alebo viac) a používateľ uskutoční nákup v aplikácii od jedného z zariadenia. V takom prípade služba Google Play odošle správu IN_APP_NOTIFY na adresu druhom prístroji a informuje aplikáciu, že došlo k nákupu zmena stavu. Vaša aplikácia môže túto správu spracovať rovnakým spôsobom spracováva odpoveď z aplikácie vyvolanej REQUEST_PURCHASE správu, aby nakoniec vaša aplikácia dostala a PURCHASE_STATE_CHANGED správa o zámere vysielania, ktorá obsahuje informácie o zakúpenej položke. Toto platí iba pre na položky, ktoré majú typ produktu nastavený na „spravované na používateľa účet. “

V druhom prípade môže vaša žiadosť dostaťIN_APP_NOTIFY vysielací zámer, keď služba Google Play prijme oznámenie o vrátení platby od používateľa Peňaženka Google. V takom prípade služba Google Play odošle IN_APP_NOTIFY správu do svojej aplikácie. Túto správu môže spracovať vaša žiadosť rovnakým spôsobom spracováva odpovede od aplikácie REQUEST_PURCHASE správu, aby nakoniec vaša aplikácia dostala správa PURCHASE_STATE_CHANGED, ktorá obsahuje informácie o položka, ktorá bola vrátená. Informácie o vrátení platby sú uvedené v Reťazec JSON, ktorý sprevádza vysielanie PURCHASE_STATE_CHANGED zámer. Tiež pole purchaseState v reťazci JSON je nastavené na 2.

To znamená, že akákoľvek vrátená platba z účtu Merchant Center spustí IN_APP_NOTIFY, keď getPurchaseInformation uskutoční sa hovor, a PURCHASE_STATE_CHANGED udalosť sa spustí a vrátená objednávka sa už nebude zobrazovať, čo znamená, že moje overenie platnosti žiadnych objednávok sa nespustí a obsah sa zablokuje.