I have an app with in-app-billing & google analytics setup and now I want to track my transactions and purchases from within the app. My issue is that I can't get my head around how I'm supposed to get the tax for the transaction.
The tax is different in each country (based on the credit-card i think) if I'm not mistaken so there should be a way to get it programmatically. I am using Googles in-app-billing api v3 and Analytics SDK for Android V4.
I dunno, I might be missing something obvious. Help would be appreciated, thanks.
I believe that you need to provide the tax amount when you are submitting your transaction hit. Check the ecommerce tracking guide. You can set the tax amount using setTax method on the HitBuilders.TransactionBuilder. Since taxes differ based on many thing (like the address zip code in US or the product category) Analytics can deduct the tax based on location alone. Your app needs to provide this with the transaction.
Related
I'm currently very much confused about with which subscription service to use between any Third-party or Google's In-App billing system.
Let me explain first , I have an app which is providing service to Landlord for Posting their vacant Properties where we are providing free trial 60 Days for full app features & after trial expires I would like to add Subscription Plans as below:
Silver: Less than 50 units (monthly or yearly)
Gold: Less than 51 - 100 units (monthly or yearly)
Platinum 100 and up units (monthly or yearly)
Now I'm exploring options to include to implement this subscription features & found that Stripe would be a good option for me but soon I find out about in-app purchases guidelines where they mentioned that In-app purchases must use Google Play’s payment system & also mentioned , examples of products not currently supported by Google Play In-app Billing:
So , basically there are two questions from my side :
Can I use other payment system or should I need to use Google's Play Billing system ?
For Google's Play system , How can I divide or how many subscriptions items will be there for above subscriptions plans?
Any help would be appreciated!
You can use both services Stripe and Google IAP(In App Purchases) or just 1 of them.
I suggest that you go with Google IAP since you do not have BE(BackEnd) and as I understand would be hard for you to maintain card numbers and everything.
Google IAP provides an SDK so that you can manage subscriptions on the Play Developers Console yourself. It also provides sandbox environment so that you can test it but also Stripe does that.
Here are some references:
https://developer.android.com/google/play/billing/billing_subscriptions
https://developer.android.com/google/play/billing/billing_overview.html
but I guess you have gone through them already. In the company that I previously worked on we were developing a project with pretty much the plans you described above and we used Google IAP and Apple IAP(for iOS/tvOS) without any problems. Furthermore we were able to query Google or Apple for previous subscriptions and let customers actually renew them instead of buying new ones.
As you mentioned the leasers/landlords will not be able to pay electronic bills with Google IAP but you can integrate Paypal/Stripe/BrainTree/WePay or any other alternatives for that.
Having mentioned that I would like to answer your questions now:
1) Yes you can use Stripe instead of Google IAP
2) You can divide subscriptions and you can manage them in your Google Developers Console at https://play.google.com/apps/publish/. However that can happen after you uploaded an .apk in console with in-app-billing dependencies and also permissions.
Hope it helps!!!
Your particular scenario is a bit of a grey area.
As a precedent the Autotrader app in the UK is using direct credit card billing in-app and this is a similar service to yours - i.e they are selling listings.
This seems correct to me because in app billing is designed to be used for digital content to be consumed in the app - not for real world services. Google may even reject your app for it.
In this case my advice would actually be to use Stripe or some other billing platform.
As for your billing model - it doesn't really fit the subscription model. I don't know specifically about Stripe but with Google you can't have a subscription AND a limit on items in the way you describe. So you would have to manage the listing limits yourself on your own backend.
There are some edge cases though - what happens if you use all of your 50 listings within the month? Do I have to buy another whole subscription?
The most suitable payment model I can see for you is Metered Billing from stripe - essentially pay as you go.
I recommended to use Google's In-App Billing. Because most of country payment support by google and user first trust on google that most benefit for you.
As I have opened account, I got this kind of tax info related message on Google Play Console.
As per Indian tax standard its asking for GSTIN info as per my business.
But I don't have any registered business exist so I am not business tax payer of the country so I don't have this kind of GSTIN number.
So what is the solution in this case for me?
Now I got proper reply from Google Support Team and posting here so if other users have noticed same point then they can get relief.
Please read content of attached image so that you will get whole idea.
I have contacted google payment help desk. If you are an individual developer you can ignore this error let the banner flash. Google currently does not have category as individual tax payer and businesses.
This error will not affect your application uploads. This will also will not affect your payment receipts.
I am conducting a beta test and trying to get a much wider audience to participate testing a new subscription service I have added to my Google Play app. I am having trouble getting volunteers outside my inner circle because subscriptions require a payment option setup on Google Play.
I don't blame folks for not wanting to do this. I can say that the charge will be zero, which is how it actually works, but there are obvious trust issues with strangers/volunteers.
I need to create a subscription that won't cost anyone anything but Google Play won't let me create a product for zero money.
I thought a promotion code would be awesome until I find out that there are no promotion codes for subscriptions.
How do I set up my subscription so that folks aren't asked to use their credit cards, is it possible?
Technical Requirement. We authenticate the subscription id on our back end, so we need a legit subscription ID to unlock the service.
I found no other way than to require my beta testers have a legitimate means of payment in addition to requiring their email to be on my white list. There are no promotion codes for subscriptions. This is the only way to do it.
In May 2019 Google has introduced promotions for subscriptions - More Info:
https://developer.android.com/google/play/billing/billing_subscriptions#promo
Promotions, or promo codes, let you give away one-time products or
trials to subscriptions free-of-charge to a limited number of users.
To implement promo codes for subscription trials, see Implement a
promotion.
I have paid Android apps on Google Play. I'm using Google Checkout XML API (notification history, specifically) to retrieve order details. I'm in the USA, and some of my customers are not. For overseas orders, the Google Checkout API returns the order amount in native currency, not USD, and doesn't provide the exchange rate, either.
On the Google Checkout site, on the other hand, I can see the USD revenue amount in order details, and it matches the eventual payout perfectly. They display order total in native currency, then the fee, then my profit - first in native currency, then in dollars.
I'm afraid that if I'll use the native currency and apply one of the publicly available rates, the dollar amount will not match Google's. And reconciliation with the eventual payout would not be possible.
I've set the notification API version to 2.5. I'm retrieving every possible notification for an order. There's no USD amount that I can see, and no rate.
Short of scraping the Google Checkout web UI, any ideas, please?
Link: someone else admitting the problem.
EDIT: I actually had Checkout screen scraping as an interim solution. Then they've rolled out the new Wallet merchant page, and it became much less friendly to scraping :(
Is there any way of getting to know who has bought your app on the Android Market? I currently haven't got an account on the market, my app is still in development so i'm asking you guys.
I'd like to know and make a list of the people who purchased, or downloaded for free, my apps. Not their email addresses or anything, just some unique usernames, maybe from the Android Market itself. Is that possible?
If not, is there any way to get this information AFTER the app has been bought? The in-app billing system i'm guessing is anonymous as well, as it's still part of the Google/Android Market billing system. But if i were to use PayPal to make "my own in-app billing" would that work? I'm guessing i can see any PayPal transactions from where/who it originated, no?
If someone can offer me a suggestion on how i could get this information, with the user's willing participation of course, i'd be grateful.
To track users, people generally use some kind of Analytics app:
Google Analytics for Android and Flurry are popular, to name a couple.
I know of no other way to track general downloads, other than the Android developer dashboard/console
To answer your first question:
Google Android purchases (market and in-app) show up in the Merchant section of Google Checkout.
EDIT: Also, once a purchase is made, it is not anonymous and you as a merchant have freedom to contact the customer directly.
EDIT #2: To address your second comment:
From https://checkout.google.com/sell/orders a merchant can see the following information for each order:
Google Checkout Order Number
Total $ (or other currency) Amount
If they've yet been charged/pending/or other Credit Card/Other processing problems and current status.
Order Details (Include user name - which is Full Name - and App Name)
Additionally, within each order you get:
Customer's full name
Billing Address
Full email, not masked
Sold on, Charged on, Confirmed on Dates/Times
App name ID
So, Quite a bit information.