I have published my app in Huawei AppGallery.
Users make purchases (In-App), I can only see the number of purchases the next day.
But I can’t verify the user’s purchase in any way, but only believe them.
In Google Play, I can enter the email or GPA number of the purchase and check when it was made and if the transaction was successful.
In Huawei AppGallery, I did not find this anywhere. Can you please tell me where can I find this option?
After all, it is the most important option for developers, I do not believe that it does not exist. I also need to know about the purchase this day, not the next day.
In the developer console, you could download the report as shown below
To track real-time transaction results, you could add "viewing the purchase history" in your app. Once this history is successfully obtained, you could either pass it to your server or save it in the app.
Alternatively, you could confirm the purchase by verifying the purchase token (from InAppPurchaseData) to confirm the purchase as well.
According to your description, you can go to Developer Center > My Report > Payment Report.
You can search for all subscriptions under your app by keywords such as the app ID, time, and order status.
https://developer.huawei.com/consumer/en/console#/myReport/payment
Related
I have recently submitted my app in Appstore with in-app-purchase feature,
it is work fine in live server but, some customer pay the payment in my IOS app not updated his profile in my server database,
Can i get User Payment details in my iTunes account on developer side for checking payment based on orderID.
If it is possible where i can get details in iTunes account or any other possibility.
Thanks for your help.
It's not possible to get any sales related data for us developers, like Apple ID, form of payment, Credit Card details etc.
Please clarify, what you want to do exactly.
The only thing you can do it "Receipt Validation", from within the app: https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Introduction.html
While transferring the app first time to one account to other its simply done by accepting the review by other receiving account.But when I tried to retransferred app its showing the
As part of Family Sharing, this app is available to all users who’ve purchased it. To complete the app transfer, you must authorise Apple to enable all previously purchased iOS apps to be shared as part of Family Sharing on a permanent basis
in the recipient account. Here New Meta Data and Accept button is not enabled. I did't find any suitable link for this. Can some one tell me that how to fix this issue?
We were into the same scenario and we solved the issue by requesting a paid application agreement from the recipient account page.
Disclaimer: this might not be a solution for all instances but in our case it was the only way to proceed with the transfer process.
Goto itunes connect using the destination account
Goto agreement, tax, banking
Don't open the transfer agreement. Instead, click on the "request" button on the "iOS Paid Applications" agreement on top of the page.
Review the information and accept the agreement. You don't have to provide the entire information but just request it.
Go back to the previous page and open the transfer agreement. You should now be able to accept it.
The recipient should enable Family Sharing on his side.
Family Sharing can be enabled for your apps by accepting the latest
Paid Applications agreement in Agreements, Tax, and Banking. To enable
Family Sharing for customers who have already purchased your apps,
ensure that you’ve selected the appropriate checkbox on the agreements
page.
We are three guys, who have made a free game for iPhone, which has been available on the App Store for almost a year.
The app is a board game, where you create a user or login using your Facebook credentials. You are able to log out of the game and log back in with another account.
Now we have updated the app with the ability to upgrade the user to a premium user. Allowing personal and global game statistics.
But Apple is giving us a headache in the approval process, and refuses to accept our In-App Purchase. First they would not approve it, as it had no restore button. Then when we told them, a restore button was not required, as it was a consumable purchase, they now demand we change it to a non-consumable and add the restore button.
Consider this scenario if purchase was non-consumable.
User logs in.
User upgrades account to premium
User logs out.
User logs in with a different account.
User restores the previous purchase.
This would allow you to upgrade two accounts to premium, but with just one purchase.
Apple's argument is, that our users need to be able to restore purchases, if a new device is setup, or a device is restored.
But that is not the way it works. Users upgrade their accounts to premium accounts. Now when they buy a new device or restores an existing device, they just log in with their existing game account, and the upgrade will be available, because we on the server-side has marked the account as a premium account.
So my question is basically. Were we totally wrong, when we choose to use a consumable instead of a non-consumable. And if so, how should a non-consumable be implemented in order to be (potentially) purchased more than once with different game accounts on the same device?
And secondly, if we are correct about the usage of a consumable in-app purchase, what should we say to convince Apple, that we are on the right path?
If your premium account is something that your users have to buy only once then Apple is definitely right to ask you to switch to non-consumable in-app.
The scenario you described is quite possible (i had to face it too) but if you add server-side verification of in-app receipts before unlocking the premium feature (saving all transactions associated to a user) you have the chance to verify that the purchase is new or restored checking the fields original_transaction_id and original_purchase_date in the receipt data. This way you can see if the user restoring the purchase is the same that originally bought it (maybe checking its facebook user id).
Anyway, experience showed me that the chance of this happening is not really high and i wouldn't recommend implementing this check (although server side validation is almost always a must ;-) )
According to the 'Restoring Transactions' section of the In-App Purchase Programming Guide:
If your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
If your app contains non-consumable purchase, and if you don't include a restore button apple will not approve your app.
This has been made necessary by apple after June 2012.
So to answer your question: No, it seems that you must use restoreCompletedTransactions.
Hope it helps you.
i have a news reader app. i want to add IAP to my app.
i added Consumable Purchase. when the user purchases i write expire date to nsuserdefaults.
when it expires i show purchase screen again.
but apple rejected it,
it says:
However, based on product functionality, it would be more appropriate to use the Subscription In App Purchase type because the service offered by your application requires the user to make an advance payment to access the content or receive the service.
...
Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
....
first i tried to use Auto-Renewable Subscription, but my app doesn't have any content to be downloaded.
then i tried to implement Non-Renewing subscription. but people say that it is deprecated.
i want to allow users who buyed app to use it on other devices too.
but i can't get AppleId (Apple doesn't allow it either).
I'm really stucked.
how can i add monthly subscription to my app?
can anyone give me some advice...
I've been through almost the exact same thing. Here's what you do:
First off, although Apple's documentation seems to suggest that Non-Renewing Subscriptions are deprecated, they are not. In fact, that's what Apple steered me towards when they rejected my app for using Auto-Renewing subscriptions.
In terms of syncing across multiple devices: I tried using a unique identifier that I stored on the user's iCloud account to identify a user (like what #Yorxxx suggested), but Apple rejected the app again, saying that the guidelines state that I need to provide an optional username/password system to allow a user to restore their subscription onto all their devices.
A few notes about Non-Renewing Subscriptions:
You set and track your own durations and expiration dates.
You essentially have to administer the service from your own server, since you'll need to sync a user's subscription across all their devices.
There is no prompt asking the user if they want to send the developer their contact information.
restoreCompletedTransactions is useless with Non-Renewing Subscriptions.
If I were you I would store the persons username on iCloud if they give you one. That way, when they install your app on a new device, you can prompt them that they already have an account and if they log in, their existing subscription will by synced to that device.
I'm considering posting an app to the iphone app store, but I'm curious before I start paying them for the priviledge of posting the app, whether they provide instant payment notification to a url?
Generally, I've used paypal in the past for applications where right after payment my web site is secretly notified of a purchase. I take this notification, with the users email address and product purchased, to send the purchaser information required for the application.
Is this possible with apple? With the iphone app store? What about the upcoming mac store?
thx
No. Apple handles all contact with the customer, including delivery of the app. At the end of each day, week and month they give you summaries of sales of each product in each country. It's nothing like selling with PayPal. The iOS and Mac App Store are exactly the same in this regard.
The nearest you can get is having your app connect to your server when it first runs, although if you're doing this for no other reason than to track your users, you'll have to check it's allowed under the developer agreement.
First, no, you do not receive instant notification. You can grab a daily report on the web the following early morning (in the US), you can use the free app that Apple provides to retrieve the information, or you can use a variety of third-party tools to do the same.
Second, you will never receive any information whatsoever about the people who buy your app, so no, you can't send purchasers anything.
The Mac App Store appears to use the exact same arrangements.
If you use in-app purchase, you can get an instant notification to your server for the in-app purchase, but not for the initial download of the app.
If you just place a paid app in Apple's App store, you get no direct sales or customer information of any kind, only after-the-fact daily and weekly sales trend estimates, and monthly sales reports a few weeks later. Then Apple then pays you 70% of what they reported up to 45 days after the monthly close. You don't pay them. They pay you. And with over 300K apps in their store, and no other store doing anywhere near as well, they need no privileges granted from any developer. It's more like take it or leave it.