Would like a plugin for In-App Payments (IAP)

[eseidelGoogle]

Or at least help building one. Requested by @lukef

[saads]

Second this. For monetization purposes we need both IAP and ad support. These are both are really critical to getting traction for flutter in the developer community.

[saads]

@sethladd

[sethladd]

@saads thanks for the feedback!

[saads]

@sethladd no worries! Any road map for this? Or any way I can help to accelerate bringing in app purchases to Flutter? Got an urgent need for it and really want to be able to use the platform because it's so helpful with accelerating development. Let me know! :)

[eseidelGoogle]

We have no ETA on writing this plugin ourselves. However you can always just use normal iOS or Android APIs or SDKs from the Objective-C/Java parts of your app and then communicate to the Flutter parts via https://flutter.io/platform-channels/.

This bug is about bundling those bits up so that folks can use common payment APIs w/o having to write any Objective-C/Java code themselves, which means taking that code you could write above, but then also bundling it up into a https://flutter.io/platform-plugins/ container.

[collinjackson]

/cc @goderbauer

[JackAppDev]

I made an iOS implementation https://github.com/JackAppDev/flutter_iap/ if someone wants to help me out by adding android support that would be great.

[sethladd]

Thanks very much for the iOS implementation!

[xster]

Tentatively closing this. The plugin @JackAppDev created seems to support iOS and Android.

[frederickcook]

Note that IAP (in-app payment) functionality (such as in the flutter_iap plugin) is a subset of Apple Pay used for selling digital goods of which Apple takes a 30% cut. This plugin is not useful for an app that sells physical goods or services and simply uses Apple Pay as a simpler alternative to credit card input.

[lykhonis]

Linking a plugin I am working on that features non-consumable products for iOS and Android with products caching and purchases restoration.

[MarkOSullivan94]

@JackAppDev would it be possible to get @frederickcook's post in your README.md for your plugin? Would make it clear to anyone using your plugin that Apple will take a 30% cut.

[mit-mit]

Renaming this back to In-app Purchases (as it started originally). I logged #17837 to track physical good transactions. If you would like that support, please vote (using the thumbs-up button) over in that issue.

[mit-mit]

We expect the present plugin to wrap the following APIs:

Android: Google Play Billing
https://developer.android.com/google/play/billing/billing_overview

iOS: In-App Purchase
https://developer.apple.com/in-app-purchase/

[gluix20]

@mit-mit do you have a tentative release date for the plugin?

[outdoteth]

@zoechi @mklim can we get an ETA for when this package will be available? 1 week? 1 month? 3 months?

[eseidelGoogle]

In general it's very difficult to make predictions about the future. But all Flutter work is done in the public (on GitHub), so following bugs like this one you'll see all the changes being made in this space as soon as they're made.

[pierotofy]

I second other people's comments that having an official IAP plugin from Google would inspire confidence in adopting the platform. The risk of not having a stable and reliable monetization feature is a big stopper for considering adoption of the platform. 👍 Nice to see work done in #24540 toward this effort.

[Hixie]

(I set the milestone for a minimal viable product version of the plugin; after that we expect to have more to add, but we'll do that as additional later work in other bugs.)

[mklim]

This is taking more time than we originally estimated so I'm adjusting the milestone. Thank you everyone for your patience.

[mklim]

This is now available in beta: https://pub.dartlang.org/packages/in_app_purchase. Thanks everyone for waiting! Please file any feedback as new issues on the tracker.

[LinusU]

@mklim sorry if this is not the correct place to ask this, I was just wondering about the background to having a global event-emitter and having the purchase methods not return anything. To me it seems like a much more natural API to have e.g. buyNonConsumable return a Future<PurchaseDetails>. This is indeed also how the other IAP Flutter plugins behave.

The drawbacks for me is that it forces me to split up the logic around my IAPs into different parts of the app, and makes it harder to reason about the flow of the purchase. E.g. I have a page that handles signup which requires a subscription. That page then needs to create an account with our backend, to which it also sends the receipt id from the subscription.

Now I need to coordinate two different pieces of information from two parts of the app. 1) the user details from the page state, and 2) the purchase id from the global listener.

Had buyNonConsumable instead returned the PurchaseDetails this would be very simple:

onPressed: () async {
  final purchaseDetails = await InAppPurchaseConnection.instance.buyNonConsumable(...)
  await FoobarApiClient.instance.signup(_emailController.text, purchaseDetails.verificationData)
}

Is the current API designed and thought out, and it's actually the better way for some reason, or was it implemented this way because it was the easiest to get thru the door quickly? If the latter, I would be happy to submit PRs to help on this, since I would like to use this in my app ☺️

[adriancmurray]

Just another flutter user here with some thoughts on this: the global listener allows us to listen for events coming from the App Store itself. Which you’d require a background listener regardless of having a future option, making the future you’re proposing a bit redundant. I don’t think you are forced to put the logic in two places, though you are a bit more forced to use something like scopedmodel or bloc. I am placing my listener at the top of my tree in a stateful widget that’s attached to a scopedmodel and this is where I’m handling all of my IAP logic. I have a feeling they choose to do it this way to help force developers to work in a manner similar to this while also choosing the solution that allows for you to listen to the app stores for whether or not you’ve marked the purchase as completed even if the app crashes, which is needed by apple.

Good job, team Flutter!

[LinusU]

[...] making the future you’re proposing a bit redundant.

I personally don't feel that it makes it redundant. In most cases, resuming an interrupted purchase is a different flow than when making a new purchase. E.g. in my case, resuming an interrupted purchase would involve asking the user for the signup details again, since if the app crashed I won't have them.

I don’t think you are forced to put the logic in two places, though you are a bit more forced to use something like scopedmodel or bloc.

That could absolutely work, but it's quite a lot more work than just await-ing a Future. While using e.g. the BLoC pattern is certinely good in many apps, I don't think that plugins should conform themselves to a specific pattern. It seems like there should be easy to implement the BLoC pattern even if buyNonConsumable returned a future with purchase details.

I have a feeling they choose to do it this way to help force developers to work in a manner similar to this [...]

If this was indeed a deliberate decision to force developers to use the plugin in a particular way, I think that we should add documentation for that to make it clear how we're expected to use it. I'm still not sure I'm understanding how to implement crash-resistance, and what events will be emitted if my app crashes during a purchase. If this is as you say "needed by apple" I think it's even more important to document it, so that developers (including me ☺️) knows how to properly implement this.

Good job, team Flutter!

Totally agree, I'm very happy for both Flutter and this plugin! Just trying to see if I can help out lowering the barrier for developers to use this plugin ☺️

[ghost]

I don't know what led Flutter team to this approach, but this is not what I expected. In my conception, Streams are preferable when you are supposed to receive lots of responses that update the screen accordingly and do not block user experience. In this case, you are making a request and the user is supposed to continue to use the app only when the response arrives.
IAPs are pretty simple and straightforward, I cannot see the need to separate the request and response in two different places, unless the developers had no other option, which I think is not the case, since other similar plugins do use Futures.

[adriancmurray]

The interruption was a side note but you’ll still need a global listener for when users make a purchase within the store itself. That’s the part that seemed redundant since that should be the same flow as a direct purchase and you’d need user details there as well.

The requirement by apple is in the documentation when you look in the files themselves. It’s where I found out about the requirement.

My point if it was designed to force a specific pattern was pure speculation. It just seems like something you should do for a flow that can handle any events that could potentially happen in one place. This means you can also catch when a user changes their subscription. Another thing you’d need a listener for.

[mklim]

Thanks all, I responded over in #32423. This issue is already pretty long and was originally just tracking the existence of the plugin at all, so I think it would be better to have new specific discussions about the actual plugin in new and separate issues so they're easier to follow and track. Feel free to cc me directly on them too.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.