Stripe (limited country) or BrainTree would be a great start
I just published an npm module that implements Stripe Checkout through a WebView, so you can use it on Expo apps without detaching. The link to the repo: https://github.com/briansztamfater/expo-stripe-checkout
I hope it helps!
By having native form and not a alert screen form with a input is more acceptable, also we can manage the language of the texts based on device language. +1
i'm moving this back to open. you can use https://github.com/expo/stripe-expo but i imagine that people want some native integration and that is probably what this feature request is for.
@Brent Vatne: stripe-expo is not longer a valid way for use with Stripe. At least not if you build your own order page within the app. You can still use it within a web browser with Stripe Elements or Checkout. But it would be really nice to have it "native" in the app. So this feature is more then ever requested!
@Brent Vatne: I'm under the impression that stripe-expo is no longer PCI compliant, though, right? I thought any CC fields had to be provided by the same party creating the token, hence their DOM-based Elements API. So we cant build our own CC fields in the app and pass them to the stripe API, but since there's no DOM we also can't use Elements to inject a Stripe CC form.
Do you mean to solve this FR together with https://expo.canny.io/feature-requests/p/apple-pay--android-payments?
Clarification of what is "In Progress" would be great
@Brent Vatne , could you clarify please? :-)
@Jesper Madsen: +1
@Whynot @Jesper Madsen: payments api itself is not actively in development -- we're working on supporting opt-in modules when building standalone apps, so you will be able to opt-in to using the payments api and not have to detach.
Thanks for the clarification @Brent Vatne ! Great to hear that. I would love to get an ETA for 'opt-in modules when building standalone apps'. Expo 25.0? 26.0?, because depending on this feature I may leave expo to pure react native... But I'd love to stay with expo because of the streamlined processes and short setup -time :)
@Whynot: not in 25 or 26, unsure about when exactly sorry
@Brent Vatne: Okay, good luck guys, expo is great! This is gonna be a very valuable thing for Expo. P.S. I'd love to see the Sources functionality too (tipsi-stripe has createSourceWithParams(params) -> Promise
to handle iDEAL, SOFORT, and other european payment methods), but I didn't find this function in your payment API...
Seriously, this may be the most valuable add on for expo EVER because it will make it possible to make PROFITABLE APPS in expo way more easy!
@Brent Vatne: Just to confirm, once added, this Payment API will either directly support IAP as an Expo service, or support 3rd-party IAP libs like the ones below, correct? And if yes, which?
@Chris: as Brent wrote it above, they plan to add support to the payments api. That api is unrelated to the packages you've mentioned.
@Brent Vatne: opt in modules would be HUGE. I can't believe I missed this comment. Months later now, does it seem like it is still coming in 28?
@arcom: we have a 37,000 line diff for the first part of this internally.. might ship that in a week. then we need to build infrastructure to take advantage of that
@Brent Vatne: cool. great to hear.
Can someone from Expo clarify what exactly you guys are planning on adding? Can't we just create a form and send a request over HTTP to Stripe to perform pretty much anything?
Does it can support wechat or alipay in China?
Trying yo understand purpose of this being on expo side, as we can already use js implementation via rest api to make payments. Also this won't enable things like touch id payments / subscriptions etc... ? Wouldn't native iOS / Android payments work better?
@ilja: Did you implement payments via API for cross-platform (Android, iOS) Stripe payments without detaching to ExpoKit?
Is Stripe allowed by Apple? I am almost sure all payments must go through Apple so they can take the 30% cut.
@Petr Peller: Not all. If you use the payment information from the app store then yes, they take 30% but if you use stripe api to get a token and create a charge from your server it's completely different. Airbnb or Uber don't pay 30% to apple.
@Nicolás Serrano Arévalo: Ah yeah, I think there is a rule that you can only offer physical products with 3rd-party payments, right? All in-app purchases must go through Apple.
@Nicolás Serrano Arévalo: but you can’t place a button or call to action inside the app coz Apple will reject your app, so how come Airbnb and Uber do that ?
Oh they can do it coz their service is outside the App Store, like Starbucks or hardware service....
@harry porter: yea, if the payment unlocks something inside of the app then you must use the AppStore payment.
No ETA for delivery but we are working on this.
@Brent Vatne: Stripe?? or BrainTree??
@Matias Saguir: we're working on stripe integration, not using the native sdk
@Brent Vatne: ok, thanks
@Brent Vatne: If not native, then what? just UI?
@Brent Vatne: can't we already just use stripe API? I figured biggest pain point was in app purchases which by TOS has to go through apple or a doors payment systems so they can get their %?
Asking if this is true more than sayingit is true.
@Brent Vatne: is the relese of this API planned in SDK 19?
@arcom: yes, Apple will try their best to get their cut
Cant you just use HTTP? It seems like half the time apple is going to force you to go through them otherwise.
@arcom: Oh yeah, I can do that with let say BrainTree? They have an REST API or something?
@arcom: yup this is a good solution
@Brent Vatne: Is it a good solution? Doesn't that involve handling sensitive data (CC info) manually?
@arcom: Did you take this route in your app? Was the flow like App => Stripe => App => Custom API? Eg were you making HTTP calls to Stripe directly from the app to avoid sensitive information being sent to your server? I think it might be possible this way to only send Stripe tokens to your server...?
@Isaac Hinman: I didn't end up adding payments. I don't see why this is any worse of a solution than when you use Stripe in a webapp. You just send it to an endpoint owned by stripe not your own custom API. Why do you need to send it to your server?
The bigger issue (that I know nothing about) is if this is okay with apple. I thought I read somewhere that apple expects you to go through apple pay (so they get their 30%) if you are going to be selling subscriptions to your app-- but I have no experience here and never parsed through apples terms myself. I would think they'd have to do this, otherwise who is going to use apple pay when you can just HTTP stripe and avoid paying them 30%?
@arcom: In my case, a physical product is being sold so this is not a concern. I suppose the main downside to a full-HTTP-Stripe implementation is that you miss out on native Apple and Android pay systems.
@Isaac Hinman: Yeah you do miss out in a slightly smoother payment process I suppose. In my mind though, if you can build your product now using stripe, then I would bet expo will have figured something out in the next 6-12 months and you can transition over then. That's probably the way I'd approach it at least.
@arcom: Have you built prod apps with Expo? Would you be willing to move this conversation to PM somewhere?
@Isaac Hinman: I think my name is the same on expo slack channel if you want to try there. Or let me know your name for the expo slack channel.
@arcom: Just messaged, cheers.