Understanding In-app Purchases
While the below content talks about Apple's In-app purchases, pretty much everything applies in the same manner to Google's In-app billing for Android
When you want to sell something to your native app users, you have to use one of the two payment platforms :
Apple's In-app purchases
3rd party platform like Stripe, Paypal, Briantree etc.
This screenshot shows an example of In app purchase (pay via FaceID)
You are probably already familiar with Stripe, since it is the most popular way of processing payments on bubble apps. You can broadly think of In-app purchases as Apple's own version of stripe, but much more restrictive and limited. Further, Apple takes a cut of 15.0% for every charge (successful payments per subscriber). This is much higher compared to Stripe's transaction fees of 2.9% + $0.30 for every successful card charge.
In addition, you can't set dynamic prices, create dynamic products, cancel subscriptions at any time, generate payment analytics and dashboard etc. using In-app purchases. These interfaces are all limited to what Apple provides on its Appstore connect portal (i.e. Apple developer portal).
Because Apple requires you to use in-app purchases for certain types of services / content sold.
In a nutshell, when you want to sell something in your native app you have to figure out if you can use 3rd party platforms or In app purchases. This depends on what & how you're selling.
The general rule here is if you are selling goods or services “outside of the app” you must use a payment service other than IAP (such as Stripe). If all that you are selling to the user is provided within the app/device itself (aka “digital goods”) then you must use IAP.
At this point, you should go through this article that explains the comparison pretty well: iOS Renewable Subscriptions Overview: Stripe vs. In App Purchases
Also see Apple's Guidelines here (Section #3)
Amazon - Sells physical goods outside the app. Hence their app implements their own payment systems.
Uber - Sells physical service outside the app. Hence their app implements their own payment systems.
Headspace - Sells mindfulness content inside the app. Hence their iOS app has to use In app purchases
Check out headspace. Consumers can subscribe to it both on the website as well as the native app. Obviously headspace prefers that customers subscribe on the site (saving them the 30% apple tax). However, apps requiring In App purchases are not allowed to inform users from inside the app that they can to go their website and purchase the service. Infact you cannot even link to such a page from inside the app, otherwise you are violating Apple's terms since you're bypassing their In app purchases (and hence taking away their cut). They will not approve your app during review. If you try to do this after approval & listing on Appstore, they will remove your app from the store and could even ban your developer account for violating their terms.
Something Netflix and Spotify have done (both serve digital content within the app) is to not have an option for users to subscribe on their apps altogether. You can only login. Given how popular they are, the next logical step for the user is to open their site and subscribe there. Then open their app and login.
Remember that these apps are not allowed to even indicate to the users that they should go the site. They are betting on the fact that the users will go their site after not finding a way to sign up on their app. Ofcourse they probably lose a good number of potential customers because of this. However, not paying the 30% apple cut is worth it, especially if you're a popular service,
You create and manage your In app products in your Appstore connect account for iOS and Play store console for Android.
These cannot be created / modified by your bubble app or native app. They are hosted by Apple & Google on their servers.
Any purchasable digital item through in-app purchases is called a product.
App Store offers four different kind of products:
Consumable: These are products which can be bought again and again after users have consumed them
Non-consumable: These are products bought just once. In subsequent app installations users do not pay again to acquire them; instead these products are restored from the App Store
Auto-renewable subscriptions: Users can buy content or features for a certain period of time. Upon expiration, subscription is renewed automatically. Users have always the option to cancel
Non-renewing subscriptions: Similar as above, but the subscription does not renew automatically. The content of the in-app purchase also differs
Play store offers two different kind of products with ability to consume them, thereby making it similar to the 4 kinds for App store mentioned above:
Managed products
Managed subscriptions
Your payments are handled by Apple & Google as well. In essence, the customer is buying your product from their store.
They transfer the balance amount after taking their cut to your bank account details.
These details, signing of agreements etc. have to be done by your in your Appstore connect account for iOS and Play store console for Android.
Though the product creation, management, pricing, payments are all handled by you via your Apple and Google account consoles, you still need to trigger the In-app purchases when a user decides to purchase your product. BDK Native engine handles all the code part of it.
All you need to do is trigger the in-app purchase from your bubble app. Then the native engine and Apple / Google servers take care of the rest. Once the transaction is successful / failed, the transaction information is sent back to your bubble app for your use.
At this point, you should refer to the In-app Purchases (iOS) and In-app Purchases (Android) sections in the Native Apps (bdk) plugin documentation
Yes & No.
You can test the In-app purchases for products created in our BDK Native App listing
Go to BDK Native App -> Native Features -> In-app purchases (iOS / Android) and try it out.
iOS doesn't charge the card for testflight apps so you can go through the full transaction on the BDK Native App.
Android will charge the card. The product listed less than 1$ so you can go through full transaction or cancel before payment should you desire.
You cannot test In-app purchases for your products from within the BDK Native app / preview mode
This is because only products listed on the account which owns the app are granted access by Apple & Google
When you purchase our service to get your app built, you will be able to test your products on your app
Pretty much. However, there is one major difference. As per Android's guidelines
Developers offering products within a game downloaded on Google Play or providing access to game content must use Google Play In-app Billing as the method of payment. Developers offering products within another category of app downloaded on Google Play must use Google Play In-app Billing as the method of payment, except for the following cases:
Payment is solely for physical products
Payment is for digital content that may be consumed outside of the app itself (e.g. songs that can be played on other music players)
So there are cases where you may be forced to use In app purchases on iOS but not on Android.
We recommend looking at Android's In-app billing guidelines and deciding for yourself.
No. Apple pay is not related to In app purchases (or Stripe purchases) discussed above.
Apple pay is simply a replacement for users having to enter find / remember their credit card details and then enter it. Similar to how face ID and touch ID have removed the need to remember passcode lock for iPhones, Apple pay aims to remove the need to have credit card details handy. It is a feature Independent of Stripe or In app purchases.
Can Stripe be used in place of In app purchases
Am I limited to using Apple's In-App purchase for charging for in-app consumables?
Can Stripe be used in place of Google IAB for multi-platform apps?
What are In-app purchases
When you want to sell something to your native app users, you have to use one of the two payment platforms :
Apple's In-app purchases
3rd party platform like Stripe, Paypal, Briantree etc.
This screenshot shows an example of In app purchase (pay via FaceID)
You are probably already familiar with Stripe, since it is the most popular way of processing payments on bubble apps. You can broadly think of In-app purchases as Apple's own version of stripe, but much more restrictive and limited. Further, Apple takes a cut of 15.0% for every charge (successful payments per subscriber). This is much higher compared to Stripe's transaction fees of 2.9% + $0.30 for every successful card charge.
In addition, you can't set dynamic prices, create dynamic products, cancel subscriptions at any time, generate payment analytics and dashboard etc. using In-app purchases. These interfaces are all limited to what Apple provides on its Appstore connect portal (i.e. Apple developer portal).
Why would anyone use In-app purchases
Because Apple requires you to use in-app purchases for certain types of services / content sold.
In a nutshell, when you want to sell something in your native app you have to figure out if you can use 3rd party platforms or In app purchases. This depends on what & how you're selling.
The general rule here is if you are selling goods or services “outside of the app” you must use a payment service other than IAP (such as Stripe). If all that you are selling to the user is provided within the app/device itself (aka “digital goods”) then you must use IAP.
At this point, you should go through this article that explains the comparison pretty well: iOS Renewable Subscriptions Overview: Stripe vs. In App Purchases
Also see Apple's Guidelines here (Section #3)
Can you explain this with some examples
Amazon - Sells physical goods outside the app. Hence their app implements their own payment systems.
Uber - Sells physical service outside the app. Hence their app implements their own payment systems.
Headspace - Sells mindfulness content inside the app. Hence their iOS app has to use In app purchases
Check out headspace. Consumers can subscribe to it both on the website as well as the native app. Obviously headspace prefers that customers subscribe on the site (saving them the 30% apple tax). However, apps requiring In App purchases are not allowed to inform users from inside the app that they can to go their website and purchase the service. Infact you cannot even link to such a page from inside the app, otherwise you are violating Apple's terms since you're bypassing their In app purchases (and hence taking away their cut). They will not approve your app during review. If you try to do this after approval & listing on Appstore, they will remove your app from the store and could even ban your developer account for violating their terms.
Something Netflix and Spotify have done (both serve digital content within the app) is to not have an option for users to subscribe on their apps altogether. You can only login. Given how popular they are, the next logical step for the user is to open their site and subscribe there. Then open their app and login.
Remember that these apps are not allowed to even indicate to the users that they should go the site. They are betting on the fact that the users will go their site after not finding a way to sign up on their app. Ofcourse they probably lose a good number of potential customers because of this. However, not paying the 30% apple cut is worth it, especially if you're a popular service,
Where do I create my In app products
You create and manage your In app products in your Appstore connect account for iOS and Play store console for Android.
These cannot be created / modified by your bubble app or native app. They are hosted by Apple & Google on their servers.
Any purchasable digital item through in-app purchases is called a product.
App Store offers four different kind of products:
Consumable: These are products which can be bought again and again after users have consumed them
Non-consumable: These are products bought just once. In subsequent app installations users do not pay again to acquire them; instead these products are restored from the App Store
Auto-renewable subscriptions: Users can buy content or features for a certain period of time. Upon expiration, subscription is renewed automatically. Users have always the option to cancel
Non-renewing subscriptions: Similar as above, but the subscription does not renew automatically. The content of the in-app purchase also differs
Play store offers two different kind of products with ability to consume them, thereby making it similar to the 4 kinds for App store mentioned above:
Managed products
Managed subscriptions
How do I get my payments
Your payments are handled by Apple & Google as well. In essence, the customer is buying your product from their store.
They transfer the balance amount after taking their cut to your bank account details.
These details, signing of agreements etc. have to be done by your in your Appstore connect account for iOS and Play store console for Android.
What role does my bubble app & native app play in the process then, for In app purchases
Though the product creation, management, pricing, payments are all handled by you via your Apple and Google account consoles, you still need to trigger the In-app purchases when a user decides to purchase your product. BDK Native engine handles all the code part of it.
All you need to do is trigger the in-app purchase from your bubble app. Then the native engine and Apple / Google servers take care of the rest. Once the transaction is successful / failed, the transaction information is sent back to your bubble app for your use.
At this point, you should refer to the In-app Purchases (iOS) and In-app Purchases (Android) sections in the Native Apps (bdk) plugin documentation
Can I test In-app purchases in the BDK Native app preview mode
Yes & No.
You can test the In-app purchases for products created in our BDK Native App listing
Go to BDK Native App -> Native Features -> In-app purchases (iOS / Android) and try it out.
iOS doesn't charge the card for testflight apps so you can go through the full transaction on the BDK Native App.
Android will charge the card. The product listed less than 1$ so you can go through full transaction or cancel before payment should you desire.
You cannot test In-app purchases for your products from within the BDK Native app / preview mode
This is because only products listed on the account which owns the app are granted access by Apple & Google
When you purchase our service to get your app built, you will be able to test your products on your app
Do the same rules apply to Android
Pretty much. However, there is one major difference. As per Android's guidelines
Developers offering products within a game downloaded on Google Play or providing access to game content must use Google Play In-app Billing as the method of payment. Developers offering products within another category of app downloaded on Google Play must use Google Play In-app Billing as the method of payment, except for the following cases:
Payment is solely for physical products
Payment is for digital content that may be consumed outside of the app itself (e.g. songs that can be played on other music players)
So there are cases where you may be forced to use In app purchases on iOS but not on Android.
We recommend looking at Android's In-app billing guidelines and deciding for yourself.
Is Apple Pay the same as In app purchases
No. Apple pay is not related to In app purchases (or Stripe purchases) discussed above.
Apple pay is simply a replacement for users having to enter find / remember their credit card details and then enter it. Similar to how face ID and touch ID have removed the need to remember passcode lock for iPhones, Apple pay aims to remove the need to have credit card details handy. It is a feature Independent of Stripe or In app purchases.
Some additional links if you'd like to refer
Can Stripe be used in place of In app purchases
Am I limited to using Apple's In-App purchase for charging for in-app consumables?
Can Stripe be used in place of Google IAB for multi-platform apps?
Updated on: 06/24/2021
Thank you!