难道谷歌播放应用内计费版本3的支持退款？ [英] Does Google Play In-App Billing Version 3 support refunds?

问题描述

我已经得到了IAB V3的工作，我能够进行购买的管理项目。然而，继续开发和测试，我想退还购买，所以我可以尝试再犯同样的购买。我登录到我的谷歌Checkout商家帐户，并成功地退回购买。然而，该应用仍然认为该用户已经购买的项目。这已是几个星期，因为我做了退款所以它不是一个延迟的问题。

I've gotten IAB v3 working and I was able to make a purchase for a managed item. However, to continue developing and testing I wanted to refund the purchase so I could try making the same purchase again. I logged into my Google Checkout Merchant account and successfully refunded the purchase. However, the app still thinks that the user has the item purchased. It has already been several weeks since I made the refund so its not a delay issue.

基本上，我的 QueryInventoryFinishedListener 实施 inventory.hasPurchase（SKU_REMOVE_ADS）总是返回true，即使后退还（ SKU_REMOVE_ADS 是SKU的项目我卖）。我期待它返回false后退款已处理完毕。

Basically, in my QueryInventoryFinishedListener implementation, inventory.hasPurchase(SKU_REMOVE_ADS) always returns true, even after the refund (SKU_REMOVE_ADS is the SKU for item I'm selling). I was expecting it to return false after the refund had been processed.

如果你看一下处理退款的IAB参考，它说，你的应用程序需要被聆听IN_APP_NOTIFY消息。然而，<一个href="http://developer.android.com/google/play/billing/v2/api.html#billing-action-notify">documentation对于IN_APP_NOTIFY 是特定于应用程序内结算的V2。它似乎没有要东西是可用的V3，因为它不是在V3参考提及任何地方也没有，我可以找到它的的样本TrivialDrive应用他们使用证明IAB V3。

If you look at the 'Handling Refunds' section of the IAB reference, it says that your app needs to be listening to the IN_APP_NOTIFY messages. However the documentation for IN_APP_NOTIFY is specific to v2 of in-app billing. It doesn't seem to be something that's available in v3 since its not mentioned anywhere in the v3 reference nor can I find any reference for it in the sample TrivialDrive app that they are using to demonstrate IAB v3.

所以做的IAB支持退款/取消购买V3？有没有人尝试过​​了，得到它的工作？

So does v3 of IAB support refunds/cancelling purchases? Has any one tried it and got it working?

推荐答案

确实是一个消耗品，只要谷歌Play是关注非易耗品没有什么区别;这种区别，完全是基于你的应用程序中实现什么。因此，即使SKU你正在测试的目的是为非消耗品（例如，永久premium升级），用于测试目的，你可以把它当作一个易耗品，使用它，这样它可以再次购买。

There really is no difference between a consumable item and a non-consumable item so far as Google Play is concerned; this distinction is entirely based on what you implement within your app. So even though the SKU you are testing is intended to be non-consumable (e.g., a permanent premium upgrade), for testing purposes, you can treat it as a consumable and consume it, so that it can be purchased again.

一个方便的方式是建立一个临时的测试菜单中选择您的应用程序中（例如，通过添加菜单项检测到您的应用程序的主选项菜单中），然后让该项目的处理程序调用的consumeAsync（）方法你IabHelper实例的SKU，你要测试再购买。这将消耗该项目，从而使其立即可用于回购从您的设备。

A convenient approach is to set up a temporary testing menu within your app (e.g., by adding a menu item during testing onto your app's main options menu), and then to have that item's handler invoke the consumeAsync() method of your IabHelper instance for the SKU that you want to test buying again. This will consume the item and thus make it immediately available for repurchase from your device.

您会，当然，还是要退还从谷歌结帐购买，这样你就不会花自己的钱只是为了测试你的应用程序。

You will, of course, still want to refund the purchase from Google Checkout, so that you won't be spending your own money just to test your app.

我想补充一点，consumeAsync（）看来也能工作得很好重置测试SKU android.test.purchased，如果您使用的是这样的静态值测试。

I would add that consumeAsync() also seems to work just fine for resetting the test SKU android.test.purchased, if you are testing using such static values.

关于购买状态更新，以反映退款，我亲身经历（也有发布的其他开发人员很多类似的报道），它通过结帐手动启动退款（例如，从TrivialDrive应用程序测试购买）开天的导致的变化对产品（以INAPP_PURCHASE_STATE_REFUNDED）的购买状态。

Regarding the updating of purchase state to reflect a refund, I have personally experienced (and there are many similar reports posted by other developers) that manually initiating a refund via Checkout (e.g., for a test purchase from the TrivialDrive app) takes days to result in a change to the purchase state of the product (to INAPP_PURCHASE_STATE_REFUNDED).

（明知同病相怜，其中的一些额外的报告可以在这个话题中找到： <一href="https://plus.google.com/+AndroidDevelopers/posts/R8DKwZDsz5m">https://plus.google.com/+AndroidDevelopers/posts/R8DKwZDsz5m)

(Knowing that misery loves company, some of those additional reports can be found on this discussion thread: https://plus.google.com/+AndroidDevelopers/posts/R8DKwZDsz5m)

目前至少这部分是由于购买数据的设备上的谷歌Play的缓存。

At least part of this is due to Google Play's caching of purchase data on the device.

在我的经验，重新启动设备有时会导致谷歌播放从GP服务器刷新其缓存。因此，它可能是通过结帐由于取消或订单的退款变化也重新启动后进行检测。

In my experience, re-booting a device can sometimes cause Google Play to refresh its cache from the GP servers. So it may be that changes due to cancellation or refunding of an order via Checkout could also be detected after a reboot.

这似乎是这么长的周转期将你没有好处，因为你可以不知道什么时候用户将重新启动。但话又说回来，你知道，每个设备将最终得到重新启动，所以如果你关心的是，谁收到退款最终应使用该退还IAB产品阻止了用户，延迟几天可能没有多大关系，只要它最终发生

It might seem that such a long turnaround period would do you no good, since you can't know when users will reboot. But then again, you know that every device will, eventually, get rebooted, and so if your concern is that a user who receives a refund should eventually be blocked from using the refunded IAB product, a few days of delay may not matter much, so long as it eventually happens.

当然，要记住这个概念高速缓存将刷新重启是无证和传闻（如不少IAB3和TrivialDrive行为，到目前为止）。民间传说，他们调用它。

Of course, remember that this notion that cache will refresh on a reboot is undocumented and anecdotal (like quite a number of IAB3 and TrivialDrive behaviors, thus far). Folklore, they call it.

当用户试图购买的产品触发更新另一件事是。一旦收购启动时，系统以确保该产品是不是已经拥有的，所以它更新了谷歌播放缓存。在我个人的经验，这一直发生。但同样，这不是一个很实用的方法来检查退款，因为这将会导致显示购买对话框中的不速之客，还告诉用户一个错误信息你已经拥有的，（如果他们的做的拥有它）。

Another thing that triggers an update is when the user attempts to purchase the product. As soon as the purchase is launched, the system has to be sure that the product is not already owned, and so it updates the Google Play cache. In my personal experience, this has always occurred. But again, this is not a very practical way to check for a refund, because that would involve showing the purchase dialog unbidden, and also an error message that tells the user "you already own this, " (if they do own it).

如果本的没有的派上用场是当用户支付的IAB项目上她的设备之一，然后试图访问是由同一个帐户拥有不同的设备上的项目被用于购买它。在这种情况下，购买信息已经非常经常尚未被高速缓存了。但是，你可以把一个小纸条在购买对话框中，如果该项目已经购买，试图重新购买时应使其present设备上可用，无需额外费用。有时需要两（用户启动）购买的尝试终于得到了IabHelper.BILLING_RESPONSE_RESULT_ITEM_ALREADY_OWNED响应。是的，有点klugy，但我认为对人类而言，将与该消息并确认对话框的道歉措辞适当的突出工作，告诉他们，他们所拥有的项目，等:-)）。

Where this does come in handy is when the user pays for an IAB item on one of her devices, and then attempts to access that item on a different device that is owned by the same account as was used to buy it. The purchase information in that case has very often not yet been cached. But you can just put a little note in your purchase dialog that if the item has already been purchased, attempting a re-purchase should make it available on the present device at no additional charge. Sometimes it takes two (user-initiated) purchase attempts to finally get the IabHelper.BILLING_RESPONSE_RESULT_ITEM_ALREADY_OWNED response. Yes, a bit klugy, but I think in human terms it will work with appropriate highlighting of the message and apologetic wording of the confirmation dialog telling them that they own the item, etc. :-) ).

作为一个实际问题，你可以看到谷歌可能不希望世界上每一个IAB的应用程序的每个实例访问其服务器的每次的被访问时应用程序的购买数据，特别是考虑到他们劝告开发商做什么已在应用程序每次启动时购买了检查。这也是你的应用程序的性能问题 - 这就是缓存的全部。所以，你需要知道的触发更新缓存，而且我还没有发现在那里，这是官方记录的一个地方（除了我们presume，在code）。因此，准备把你的手在你的面前，并开始在黑暗中感觉身边。

As a practical matter, you can see how Google might not want every instance of every IAB app in the world to access its servers every time the app's purchase data is being accessed, especially given that they are advising developers to do a check for what has been purchased each time the app is started. It's also a performance issue for your app - that's what caching is all about. So you need to be aware of the triggers for updating the cache, and I haven't found a single place where this is officially documented (except, we presume, in the code). So get ready to put your hands out in front of you and start feeling around in the dark.

有关谷歌播放缓冲一些额外的信息，请参阅本页面：

For some additional information regarding Google Play buffering, see this page:

<一个href="http://stackoverflow.com/questions/15384067/under-what-conditions-are-in-app-billing-version-3-server-changes-made-available">Under什么情况下是在应用程序内结算版本3服务器更改提供客户端设备上？

我要指出，在您的文章的code片段您呼叫inventory.hasPurchase（SKU_REMOVE_ADS），但只会告诉你，如果购买的是在清查对象返回采购清单;它不会告诉你购买该SKU的的状态的。我知道这是所使用的TrivialDrive应用程序的方法，但是该应用程序不处理退款和取消。为了检测退款和取消的订单，你需要这样的：

I would note that in your post's code snippet you are calling inventory.hasPurchase(SKU_REMOVE_ADS), but that will only tell you if the purchase is in the list of purchases returned in the inventory object; it will not tell you the state of the purchase for that SKU. I know that this is the approach used by the TrivialDrive app, but that app is not dealing with refunds and cancellations. To detect refunds and canceled orders, you'll need something like this:

Purchase removeAdsPurchase = inventory.getPurchase(SKU_REMOVE_ADS);
if(removeAdsPurchase != null) {
  int purchaseStateForRemoveAds = removeAdsPurchase.getPurchaseState();
  if(purchaseStateForRemoveAds == 1) {
    //Do cancelled purchase stuff here
  }
  else if(purchaseStateForRemoveAds == 2) {
    //Do refunded purchase stuff here
  }
}

有关退款和取消的订单的好消息是，两者都是，AFAIK，完全在开发商的选择。所以，如果你发现谁得到这些用户能够继续使用您的应用程序很长一段时间后，如果您发现很多用户正在利用这一优势，那么你可以决定是否要继续提供退款的所有情况。我最好的猜测是，这将不会是一个问题;即使一些用户谁得到退款得到使用你的应用程序，为后一段时间，不见过这样一个非常大的交易。

The good news about refunds and canceled orders is that both are, AFAIK, entirely at the option of the developer. So, if you find that users who get these are able to continue using your app for a long interval thereafter, and if you find that lots of users are taking advantage of this, then you can decide if you want to continue providing the refunds in all cases. My best guess is that it will not be a problem; even if some user who gets a refund gets to use your app for a while after that, that doesn't seen like a very big deal.

这是你需要重新尝试购买非常迅速的能力测试，并使用consumeAsync（）明确适用于这一目的。

It is for testing that you need the ability to re-try a purchase very rapidly, and using consumeAsync() definitely works for that purpose.

这篇关于难道谷歌播放应用内计费版本3的支持退款？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！