Develop Reference

How or which Payment system do I need to use for Subscription services which are mentioned as below , Stripe Or Google's In-App Billing?

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.

In-app purchases: Share user In-App purchases between Android and iOS

I'm planning to add In-App purchases to my Productivity app. Enhanced features are purchase products (e.g., freemium).
I would like to have user access to purchased feature on both Android and iOS, if he has purchased on any one platform. Technically I plan to store purchase information on server and have it retrieved whenever user logs-in on either device, and unlock the feature if already purchased.
Is this allowed in both iOS and Android?
Apple App Store Review Guidelines on Section 11 have this explained.
Points "11.1/11.2" and "11.14" sounds conflicting (or I'm missing something.).
On Android, I do not see this point mentioning in Policies.
If you had any experiences (w.r.t sharing purchase info between devices) that I should take care additionally, any suggestions are welcome.

I'd like to add a note about subscriptions. Here's the quote from Apple guide:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have both an iOS and macOS version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an macOS app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions
Link to Apple docs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Quote from Android docs:
You can also build on your existing external subscriber base from inside your Android apps
If you sell subscriptions on a web site, for example, you can add your own business logic to your Android app to determine whether the user has already purchased a subscription elsewhere, then allow access to your content if so or offer a subscription purchase from Google Play if not.
You can implement your own solution for sharing subscriptions across as many different apps or products as you want ...
Link to Android docs:
https://developer.android.com/google/play/billing/billing_subscriptions.html
At the moment of writing this answer (May 23, 2017) Windows Store doesn't have subscriptions but they were announced during the latest BUILD conference. Some details here and here
Subscriptions should be available later this summer.

Answering myself. I submitted to App Store mentioning this case and got it approved. I'm yet to submit to Google Play so not sure about it.
Below the snippet I mentioned in App Store review notes that may help some
If user already purchased premium outside the app(our website or
Android app), then we are unlocking Premium as soon as user
logs-in to the app on iOS device. We do not include any button or link
or information inside this app regarding purchasing outside. If you
have any concern or comments regarding this, please let us know.
Additionally mentioned that our in-app item's service is based on user data at our server and not solely on iOS platform. I think this is the key point that makes sense to reuse user's purchase of our service. However, I do not find this case mentioned clearly in App Store review Guidelines.

[Update for April 2019]
As I've already answer here - from developer Apple guidelines:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So like #siddharth-gupta explain in his answer:
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation

In-app purchases made via promo codes return empty developer payload string

I have an app published to the alpha channel, with an in-app (un)managed item that costs $1.
When I purchase normally, i.e, use a credit/debit card Google returns the correct developer payload string, but if I choose to "redeem" a promo code and enter said code, Google returns an empty developer payload string, and thus authentication fails in 'onIabPurchaseFinished()'.
I should mention that this only occurs if I choose to redeem a code from the app's purchase flow, and everything works flawlessly if I open Play Store first, redeem the code, and then come back and open the app.
Is this a bug on Google's part?
EDIT: The Play Store thing is expected, since it can't know your payload and the purchase is done without having to check for it.

This issue was opened on the google's android-play-billing samples repo.
Looks like it was ignored for a long time and was eventually closed with this comment. In short, they have following suggestions.
We reviewed our guidelines and internal APIs, and since the developerPayload is not supported across all features on In-App Billing API (including promocodes), we are removing the recommendation to use it as a security check.
As you can see in our documentation, on the page Implementing In-app Billing (https://developer.android.com/google/play/billing/billing_integrate.html) we've added a recommendation:
Caution: Don't use the developerPayload field for security validation purposes. This field isn't always available when completing tasks related to In-app Billing. For more information about security best practices, see the In-app Billing Security and Design guide.
Our recommendation is to validate on your own backend, using the Play Developer API.

play store: combine one-time in-app purchase and subscription

In the Android Play Store: Is it possible to distribute an app for free, but provide multiple in-app purchases to unlock features, and also combine a (yearly/monthly) subscription to unlock yet another set of features?
All information I could find was the explanation to use one of the billing methods, but I couldn't find any information about combining multiple billing systems in 1 app.

You should be able to do whatever you want. Here's the documentation on subscriptions: https://developer.android.com/google/play/billing/billing_subscriptions.html and the Billing API for all the other things: https://developer.android.com/google/play/billing/api.html

Android and Checkout API for in app purchases

I want to know if its possible/legal(not against terms of service) to use the google checkout api for an android app to support in app purchases. The types of items being purchased would be something like extra coins where they can be purchased multiple times.
I know that this would require getting the user's credentials or pointing them to the checkout page or something. I want to know if its possible to do this within the app by opening a webview to the checkout process, and then getting a callback to a custom url on my server that will allow the app to see that the purchase was successful. Something like what the android market does for app purchases.
Thanks for any responses. I don't currently have code to show as I am researching into this before devoting time to create something I won't be able to use. Also maybe android will support native in-app purchases in newer versions of the sdk.

Spoke to (Android evangelist) Reto Meier at Google Tech Days about this and he said it is perfectly OK to do inter-app purchases in the market. You should comply to other regulations - most common is that you need to only buy content that is consumed on the mobile. Virtual "coins" are on quite thin ice, some countries ban issuing "virtual money" but you can do essentially the same with just little different paradigm. Hope this helps.

Android market documentation explicitly states that you can do check it.
http://developer.android.com/guide/market/billing/billing_admin.html#billing-refunds
Important: You cannot use the Google Checkout API to issue refunds or
cancel in-app billing transactions. You must do this manually through
your Google Checkout merchant account. However, you can use the Google
Checkout API to retrieve order information.