Direct Carrier Billing is a payment option provided to subscriber while purchasing an App which will bill the subscriber in their mobile carrier bill (postpaid) or deduct from prepaid balance.
Dear friends I would request to throw some light on how to integrate App in this case with Google Play store or itunes app store API which in turn will call the Mobile Carrier Charging system for charging the subscriber while purchasing paid apps or in App purchases.
Any help would be a boon to me.
Currently Google support Direct Carrier Billing (DCB) for some countries which gives Android users the option to pay using their carrier for apps and content in Google Play.
As a mobile application developer, you don't need to integrate anything.
For purchasing apps, Google Play will offer DCB option as a payment method to end-users if their carrier supported.
For in-app purchases, You need to use Android In-app Billing API and google play will offer the DCB option as a payment method to end-users if their carrier supported.
Check this also (Decide Whether your App will be Free or Priced)
To explain more I will list bellow the end user flow:
REGISTRATION THROUGH GOOGLE PLAY STORE
Go to the Play Store.
Click “My Account”.
Click “Enable carrier_name billing” under Payment methods. (appear only if carrier supported)
Google will verify your account while carrier validates your mobile number
Enter any country billing address details, “Save” and “Accept” once completed.
carrier will appear as your default payment method on Google Play.
HOW TO BUY IN-APP ITEMS
Open your app.
Go to the store for in-game items or in-app purchases.
Choose your preferred denomination for the in-app purchase.
Click “Buy”.
Enter your Google password.
Click “Confirm”.
Payment will be verified and you will receive an SMS of the successful purchase.
Related
When I integrated Google Play Billing Library to purchase Subscriptions ,it said if you do not acknowledge a purchase within three days, the user automatically receives a refund, and Google Play revokes the purchase.
But I use test account to buy subscriptions, how can I make the above result without acknowledge in test account ?
We plan to implement all the subscription server-side services. Here is the flow for our client iOS app:
The registered user enters phone number, we check if the number is valid and if it is, the user can subscribe and thus use some features of the app that an user without an active subscription can't. The subscription is not free and it doesn't go via AppStore; the user is charged at the side of his/her provider, based on his/her phone number. The user isn't asked to give any of his/her credit card data. One of the features that gets unlocked when user subscribes is the possibility to download digital content.
The question is: would Apple approve this flow? I know for subscriptions as in-app purchase types, but the plan is to have something different in our iOS app.
And what about promo codes? Is it possible for vip users to use our promo codes in order to subscribe..?
Apple will not approve any purchases that get added to an iOS device, are initiated on the iOS device, and don't go through the app store. You can do purchases through your web site; in that case you will have to avoid links to your website from the app.
On the other hand, physical purchases must not go through the app store. So if you have an app for buying hand bags, you can not get payments through the app store.
Apple will also give you a very hard time if you ask users for their personal information, like their phone number, and if there are features they can't get without giving you such information.
Here's a scenario that's not clear to me in terms of whether it's allowed by Apple (even though I've seen other apps that actually do this):
User purchases or subscribes to a web app.
User then downloads related iOS app (i.e., it has the same functions and shares the same data with the web app) and can access the iOS app only by entering their user ID and password from the web app (so essentially the iOS app is free to download but not free to use).
According to the Apple Developer FAQ page for in-app purchases:
"Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected"
"Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected".
"Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement"
"Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App"
Does the last point contradict the other three?
Does the scenario I've seen where an iOS app is activated using the user ID and password from the developer's web app fall under the first three points, or under the fourth point? Why?
I presume it's also possible that the apps I've seen are violations that fell below the Apple radar, because the FAQ page also states the following:
"In general, the more expensive your App, the more thoroughly we will review it."
I'm really having trouble untangling what's allowed and not allowed and appreciate help getting a more clear understanding of these important rules.
I'm speaking from experience here, I worked for two clients who each have an app available in iTunes, Google Play, and on the web. Both apps are monetized from subscriptions which can be purchased with in-app purchases from iTunes and Google Play and via credit card on the website.
Each app from their respective app store only offer the appropriate and allowed purchase method, e.g. the iOS apps only offer in-app purchases from iTunes, they never offered credit card purchases, nor do they link to directly to a webpage to pay by credit card.
Users are required to login and the subscription status (notably the expiry date), regardless of where they purchased from, is associated to their account in the database. This allows the users to access paid content from any device without having to subscribe again with a different payment provider. e.g. The user buys a subscription on Google Play and they can access the paid content in the Android and iOS app or on the web.
Both clients have server-side receipt validation in place which checks the status of the subscription on the expiration date.
Apple and Google seem to have no problem with this and there are many notable examples of apps doing exactly this; spotify and skype are a few that come to mind and they are big players. If your app is rejected for using this same practice then those apps are in violation too.
In my application, I have to implement a donate button with which the user can donate money to a particular organization. I have used the Paypal SDK, in which the sample code shows the purchase of some products.
How can I get an implementation of "Donation" with the Paypal SDK in iOS?
Was the organization in question a nonprofit? If not, it might be considered under the "Unacceptable" section of the "Other Business Model Issues" portion of the App Store Review Guidelines:
(iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
I have a requirement like this,
User goes to ad section in the app where all ads are displayed in the table. He will select which ad needs to be shown in the broadcast queue and at what time. The ad needs to be purchased before inserting into the queue.
The queue is a series of audio objects which are broadcasted the user. this is similar to radio.
Could someone tell me how should I go with ad purchase implementation in the app? Should I need to go with in-app purchase or via 3rd pardy payment option like paypal etc. Please provide some inputs.
Thanks.
Since an 'Ad' that you are selling is a digital good, you must use Apple in-app purchase system. That is a requirement by Apple.
You can use Paypal API (or any other payment gateway) only for purchases of physical goods. And charity donations.
Here's a link that describes it in detail.