More of a logistical question this time...
I am thinking of creating a marketplace app where users can purchase content it's important to note that this content is only viewable via the app.
When a creator sells a piece of content, I want to be able to make a payout to that creator minus our business cut, lets say 10%.
I'm sure this is much easier with third party providers like Stripe but because the content purchased and consumed is within the app, Google and Apple require that all payments are made through their respective payment provider, which is why I'm using RevenueCat to facilitate the combination of the two providers.
That's all well and good but my issue now is, how do i make payouts to the creators?
Any help on this would be great, I'm struggling to find a logical & logistical answer to this online.
Thank you
Related
have the following scenario:
we have an app that users need to pay for. But we also want to sell the app bundled with a book meaning there is a code / voucher in the book that can be used to use the app for free. Unfortunately we haven't found any good way to address this scenario yet:
a) make the app a paid app and use Google / iOS Promo Codes for the books - not good, because the number of promo codes per app and quarter is limited
b) make the app itself free but require users to make an in-app purchase to access most of the content. Alternatively make it possible to enter a code to access that same content. The code comes with the book and is created and maintained by us.
negatives: a lot of effort to maintain the promo codes, handle the in-app purchases and Google / Android don't like it if content within the app is paid for outside - so we could end up being rejected.
I'm really wondering: are we the first one with this need? is there maybe already a solution to this problem we are not aware of? We do not want to rip Google / Apple of their 30% share of app sales. But there doesn't seem to be a supported solution for this.
any ideas? thanks
Thomas
Welcome to SO.
This could be done but i dont know if this is the optimal solution.
Make the app free and lock down at the sign-in, there give link to your play books.
In the app check if the user has purchased the book using
https://developers.google.com/books/docs/v1/using
So if user pays for the book and downloads it, On the next app launch give access to him to use the app.
You should be careful with Apple's in-app purchase guidelines, 3.1.1:
If you want to unlock features or functionality within your app, (by
way of example: subscriptions, in-game currencies, game levels, access
to premium content, or unlocking a full version), you must use in-app
purchase. Apps may not use their own mechanisms to unlock content or
functionality, such as license keys, augmented reality markers, QR
codes, etc. Apps and their metadata may not include buttons, external
links, or other calls to action that direct customers to purchasing
mechanisms other than in-app purchase.
I think for users that purchase the book, they would need to register outside of your app (e.g. on your website). If you had some authentication system you could store a flag on the users profile if they've unlocked the book or not and give them premium access to your app upon logging in.
You can make your app free and set non-consumeable book SKU in your app.
If you want to send the promo code, you can use Google Play Console.
https://android-developers.googleblog.com/2016/01/create-promo-codes-for-your-apps-and-in.html
Google only allow a small amount of promo codes per app, 500/quarter. This is because they don't want to encourage developers to sell this promo code offline. But this is still an official feature supported by Google Play. You will be totally fine as long as you're less than 500/quarter.
I'm developing a pay for win Android app, in which users are, among others, ranked according to the amount they have spent. The payments are Android in-app purchases.
My questions are:
Is an authentication system required for my users, in order to purchase and be ranked? In other words: instead of using an authentication system, could I use the UUID of the phone, or its MAC address, or any other piece of information that would actually act as an authentication system? If yes: why isn't there any other Android app that proceed in this way (indeed, they use Facebook/Google authentication, or e-mail + password authentication, etc.)?
Is there any Java ranking library that I could use and bind it to the Android in-app purchases? In particular: does Google offer such an API?
Is it a good idea to use Google's authentication and ranking based on Google Play? The ranking criteria must also be the total spent amounts.
Authentication and authorization
Firstly, I would like to make the distinction between authentication and authorization.
Authentication is a way to determine a user apart from other users. Authentication allows a developer to identify Jane Doe as a separate entity from all other users. Authentication is often a precursor to authorization.
Authorization pertains to what actions a user can take on particular resources. Authorization deals with the what, when, how as opposed to the authentication that deals with who.
To state your questions using more definitive language you are asking for best practices relating to:
Authenticating a user inside an application that is available on the Google Play Store, and
Calculating totals related to Android's In-App purchasing, and
Authorizating a user to take a claim action on a prize entity depending on the aforementioned total aggregate
Recommendations
I would highly suggest you use Google's OAuth 2.0 service to authenticate users as opposed to building your own authentication framework or implementing any other authentication framework, especially if this application is only used within th Android ecosystem. I recommend this because:
Android users already have a Google account, and
Implementing your own authentication framework requires very niche skills which usually require a team of people, and
Google already offers an Subscription and In-App Purchasing API which can be queried to rank you users, and
You will already have implemented this API to support in app purchasing to begin with
I would highly suggest you do not use MAC address or UUID authentication because
On a rooted phone I can change my MAC address, and
It does not uniquely identify a user across multiple devices, and
Using this type of authentication would not provide any benefit to your second goal of authorizing actions based on a total aggregate
In other words by using Google's authentication mechanism you can not only uniquely identify users across multiple devices, but you can also leverage the in app payment system to build your particular authorization logic.
The In-App Purchasing API already contains the necessary information you want since you will need to implement it to support in app purchasing to begin with. You might as well use it as a basis for ranking since it is readily available, secure, and contains the information you need with well documented ways of accessing it.
Additionally, you may want to look at the promotional capabilities and one time product-specific billing features functions and related APIs. This might fit your use case and it may make your application more secure and standardized.
Using the provided authentication framework and in app purchasing capabilities standardizes your application up until you implement the claim your prize functionality. People enjoy standardization because they become familiarized with it, and it provided a level of trust, so I would definitely investigate the other aforementioned APIs to see if your prize idea can be based off a foundation provided by Android. This would standardize your app all the way through and, in my opinion, would be best practice.
Summary
I would provide some sample code but your questions are still a but high level to provide anything useful in the way of code snippets. To summarize though my recommendations are as follows
Leverage the Google OAuth 2.0 framework for authentication, and
Leverage the In-App purchasing API and related APIs as a way to calculate total and rank users, and
Investigate the promotional capabilities, or one time product-specific features already provided by Google to see if it fits your use case, and
Avoid using MAC addresses and UUIDs for authentication for the reasons I outlined above
Edit ....
After rereading your title I realized I glossed over the fact that, as I understand it, the term ranking and it's related functionality as used by Android is mostly centered around where you application sits, popularity wise, in comparison to other applications. I have not seen the term used by Android to refer to internal ranking of users against some developer-defined criteria ( total, in your case ).
I'm not saying it does not exist, just that every time I see ranking it refers to application popularity. Therefore I would refrain from using that as a query term when researching how to build this application as you will likely get a plethora of false positives.
What I think you want, to reiterate, is
Authentication
Calculating in app purchasing totals
Promotional or one time features based on that total
Those terms will suite you much better. Please feel free to start a new post when you get further in to the project if you need assistance consuming the APIs
I'd like to be able to link users in one game to users in another game such that users that unlock certain achievements in game 1 are able to receive special items in game 2. This is very similar to how Blizzard does it where buying like X in Hearthstone gives you a special mount in WoW.
I know we could manage our own account system but we're hoping there's an easy way around that.
I've been researching Google Play Games and it seems like that could be the ticket but I can't seem to figure out a good way to identify that this new user linked in Google Play Games is the same user as in Game 1. Is this something I can accomplish with the SDK? Basically wondering if playerId is unique to the game or to the player themselves and across different devices.
(another option would be using the Google Play Advertising ID, but that isn't great for users that want to enabled limited ad tracking).
developer.android.com has a whole article on user identifiers. What you've got is a hard problem. I can give you a few tips:
playerId is the same for the same user across different devices, but is different between different games. This is deliberate to prevent Ad tracking that the user didn't intend. So playerId would probably be the wrong choice.
The Advertising id is "for user profiling or ads use-cases". So I definitely wouldn't use it for this use case.
In this case, my choice would be to use something like Firebase, especially Firebase Auth to manage a very simple account system. You won't need to create your own servers or write much sign-in code as Firebase handles this, and you get sign-in with Google or Facebook for free. And once you have it, it will give you a nice flexible way to do other things in future, eg experiments or configuration with Firebase Remote Config. And it is cross-platform if you ever write an iOS version, and from Google.
Does there any existing good API for virtual Coins purchase in mobile application? Actually, I would like to make a cross platform application. I have researched on facebook, there is a facebook API for purchase. But it only for facebook application/games.
Generally, each app store/market wants you to use them to handle payments, so that they can take a cut (usually 30%) of your profits. Using third party payment providers is generally forbidden by the terms of use, etc. Thus, it is unlikely that you will find a cross-platform solution. PayPal should work on most platforms, but you have to make sure it's not against the terms of use. For Android, you can use unmanaged items with in-app billing, there should be something similar for the iPhone. You could probably manage your coins on your own server, and have them purchased on each platform with the required payment provider, but it's quite a lot of work.
I'm trying to write a free mobile app that would make payments merchant-agnostic for the customer.
Context: Most web-apps are merchant centric and allow for multiple payment types from the customer. But the problem I'm trying to additionally solve is to have, say, a mobile app that is capable of paying as many merchants as possible using your debit, credit or PayPal account. It shouldn't rely on per-merchant technical partnerships to work. It should just be able to talk to any merchant after writing the upfront code.
There are a few solutions that come to mind: Integrate with VISA, Mastercard, or PayPal. However, my goal is to integrate with stores that sometimes only take debit, sometimes only VISA, sometimes only PayPal, etc, while re-inventing the wheel as little as possible. I'm wondering if anybody has already solved a problem like this before?
Which APIs are the easiest to integrate against? Could you name a few?
Are there well known merchant-aggregating APIs that are already very popular? Do they cover much larger merchants like Costco and Walmart?
Are there partnership costs (with say VISA) I need to be aware of?
Is there one API to rule them all that would aggregate even across Debit, VISA, PayPal, etc to reduce things to one integration point?
I need this for a free consumer Android app and would really appreciate any help I can get - especially if it's cost-effective.
Best!
Amin
You might be able to obtain a large quantity of Paypal account info on companies who publish their account info for payment, but doing it with credit cards directly would be rather challenging as you would need the company's merchant account information and provider's information in order to process. This info is sensitive data as releasing this info would also allow you to refund yourself money using their merchant account.
Have you thought about using electronic check as a pay option instead? If so, that would allow your app to pay thousands of companies from your application without the complications of getting merchant account info. Let me know if that might be a viable solution for you and I can give you a hand with it.