Update Stripe library

[jzeferino]

The version of Stipe we have is from 2018 and relates to the version 11.4.0. Today the current version of stripe is 15.0.1.

Can you guys make an update of it?

cc @newky2k

[newky2k]

@jzeferino I'll look into it

[jzeferino]

@newky2k thank you for taking a look at this. I'm trying to work on in also. Let me know if I can help.

[jzeferino]

@newky2k I'm working on this at the moment, do you have some time to talk about this? were can I find you?

[newky2k]

@jzeferino you can message me on the Xamarin commonents gitter channel -> https://gitter.im/xamarin/XamarinComponents or DM me on twitter @davidasahuman

[robyitaly85]

Are you working for this integration? Will it covert the last version of the SDK that using the "Payments Intent" and the "3DSecure2" that are required by the recent european PSD2 requirements?

[jzeferino]

I have the binded the version that matches stripe sdk 15.0.1 here -> https://github.com/jzeferino/Xamarin.iOS.Stripe

[dinonovak]

Hi,
can I please kindly ask you to update Android binding for Stripe.
Truly gratefull.
D

[diegostamigni]

Any update on this?

[robyitaly85]

Hi,
Do you have any update about Android binding for Stripe? It's becoming mandatory to be SCA-Ready in Europe as in https://stripe.com/docs/payments/3d-secure#android

[dave-1185]

Is this version of Stripe getting an update sometime soonish? or is there an alternative library? Like @robyitaly85 mentioned we are also in need to provide a SCA ready solution. @jzeferino did you update your bindings along the way?

[deondk]

Hi @dave-1185 ,have you been able to get a workaround for this on Android? I am trying to use the current version to show list of cards but getting an issue on the Ephemeral key creation and stripe can't support as it is so outdated. Any help will be greatly appreciated.

[Cellus250]

Just giving a bump on this issue. Additionally, @deondk @dave-1185 @robyitaly85 would anyone be able to share a snippet on creating the cardentry widget that Stripe requires for collecting the card info? Or some pointers in the right direction?

[philmarland]

Is there any current update on this issue? We're keen to use this library but the Stripe iOS SDK is now on version 20.1.1 and the core version here is still 11.4.0, almost 3 years old. I'm happy to try and help contribute if there's someone we can work with to review a PR or similar. We also need to use the Android one too.

[dinonovak]

Moved to stripe.net all works like a charm, but if you want to use Xamarin Forms you need to create own GUI

[philmarland]

Thanks @dinonovak. Please could you elaborate? Do you mean just calling Stripe APIs using the https://www.nuget.org/packages/Stripe.net/ package? Then building your own UI for entering card data, doing SCA, Apple Pay etc?

I'm hoping to use the SDK features in this package to avoid having to re-implement some of those UI experiences but I'm interested in exploring your suggestion.

[deondk]

Hi @dinonovak and @philmarland - using stripe.net inside app is a HUGE security risk. It means you have to store the secret and public key inside the app which will be very easy for anyone to extract. I used the old version of sdk in xamarin and it works ok with some workarounds. @philmarland if you want you can leave your skype details here then we can have a chat and I can share what I have done?

[deondk]

I am using xamarin.ios and xamarin.android though and not forms.

[deondk]

Just giving a bump on this issue. Additionally, @deondk @dave-1185 @robyitaly85 would anyone be able to share a snippet on creating the cardentry widget that Stripe requires for collecting the card info? Or some pointers in the right direction?

@Cellus250 and @philmarland maybe we can get on a skype or google chat together and exchange some ideas?

[dinonovak]

Hi all,
if app is designed correctly there is no risk and no secret key is used in the app.
the architecture is Mobile App + API Server, this is recommended scenario by Stripe and this way there is no risk that private key can be extracted from the mobile app. Payment is prepared in mobile app, sent for processing to Server, and then based on the result Mobile app is updated and continues processing.

[deondk]

@dinonovak are you using xamarin forms? so you are building your own GUI for adding and showing of cards?

[deondk]

Sorry misunderstood you...I am doing a hybrid of the two...using stripe.net in API server to process transaction but the stripe sdk on frontend to show and manage cards.

[philmarland]

Thanks for your thoughts everyone. Useful to validate what we're planning. What we've decided to do is take the XamarinComponents stuff as a starting point but try and update it all to the latest Stripe SDK binding. Hopefully even raising a PR to get it contributed back.

The functionality wins from using the official SDKs just make that option a bit more attractive to us at this point than rolling our own UI. Things like card data entry / token encryption, SCA2 and all its complexity, Apple and Android Pay etc.

If anyone's got experience trying to update the bindings that might help us avoid problems other people have had that would be great.

[deondk]

@philmarland That is great. Please let me know if I can help or if you have any questions. With my current dev the main issue is using 3DS which is impossible to do with the old SDK. @dinonovak I would love to know how you are handling 3DS on your project?

[philmarland]

That's the main reason we want to bring it up to date, as a lot has changed in the three years since this was updated. We need to use the 3DS (SCA) stuff as well as Apple Pay / Android Pay so I'm really hoping we can avoid too much of our own implementation if there's a perfectly good native SDK that can be wrapped somehow.

I've also spoken to the relevant team at Stripe and they've confirmed they don't have any other official Xamarin packages that we're missing so XamarinComponents seems to be the best bet.

Right now we're hitting a few issues around AndroidX on the Android bindings. Will see how we get on and report back.

[philmarland]

We have created a binding project and it compiles without errors, however when we add the project to a Xamarin Android app and try to call one of the methods (eg paymentSession.PresentPaymentMethodSelection) it produces an error as follows:

{Java.Lang.ClassNotFoundException: Didn't find class "androidx.viewbinding.ViewBinding" on path: DexPathList[[zip file "/data/app/com.stripe.demo.stripe_android_demo-WavIYiuBHhr7K5nvRYv8_g==/base.apk"],nativeLibraryDirectories=[/data/app/com.stripe.demo.stripe_…}

We believe the problem is that Xamarin Android does not generate suitable files where packages use AndroidX.ViewBinding.

Does anyone have any ideas that might help us progress this issue?

[philmarland]

Also if anyone has any ideas how we can get support from Xamarin / Microsoft with this, given that this is going to result in producing a useful binding library for a really popular payment processor that does not currently have any other official or third party solution, I'd have thought they'd want to support this in some way.

[dinonovak]

HI, sorry for missing on the thread, looks like you decided to take the hard route (been there, done that). I ended up going with stripe.net, GUI part is much easire than you think. If done right you end up with fully working and flexible solution. FYI SCA is fully supported, it requires some interesting tricks in forms to get it working, but then with any new update there are no suprises.

[philmarland]

Thanks @dinonovak that's interesting and I'll bear that in mind. Certainly better than the alternative of having a web-experience hosted in a frame! I'm trying to navigate various support channels to see if we can overcome the issues we're having but have a limited timespan so we may have to revert to your approach if that doesn't work out.

I'm actually quite surprised by the lack of interest in a package like this. Xamarin Forms is popular, as is Stripe, so the lack of an existing library out there is unusual. Stripe have said they'd consider sponsoring a package once it's launched, but don't have any experience with Xamarin by the sounds of it so nothing much from them.

[dinonovak]

@philmarland I was in touch with Stipe support for quite some time and they were not able to help, so left on our own. Took some time to understand the process and how the things work.

[philmarland]

I've had a reply from someone on Gitter that suggests it won't be possible to get the newest versions of the Stripe Android SDK working in Xamarin Forms because the SDK uses AndroidX.ViewBindings and Xamarin won't support it because Xamarin has its own data binding solution. Hopefully I can verify that but if it's true that's the kiss of death for us using the Android SDK.

In fact I'd go as far as to say if it's true the Stripe Android bindings could be removed from this project since they'd be so out of date and un-maintainable they're essentially dead.

[philmarland]

We've had a breakthrough on the Android bindings and have a working prototype. The iOS one is looking promising too. At this stage though we're contemplating making our own library rather than trying to raise a PR here as this package seems pretty dead right now.

[philmarland]

We've got this working on iOS and Android now. Discovering lots of nice features of the SDK UI implementations that we'd probably have missed if we'd rolled our own. Based on the feedback on #1010 though, I'm going to work on the assumption that it just isn't going to get merged if I raise a PR to contribute this back, so we'll probably create our own repo.

The most useful answer I found, leading to the steps we followed to get the Stripe Android SDK working, was this answer on the AndroidSupportComponents repo: xamarin/AndroidSupportComponents#154 (comment)

Specifically, for anyone else trying to get third-party SDKs that depend on AndroidX working with Xamarin Forms:

1. Download the AndroidX.Core library and its dependencies from the Maven-repository.
2. Create a new directory and unpack all downloaded JAR-files into that directory.
3. Open the AAR-files with an archiver-tool, extract their classes.jar-files, and place the contents of the latter in the above directory as well.
4. Run "jar cvf androidx.jar ." within the aforementioned directory to package all AndroidX-files together in a new JAR.
5. Add this JAR to your Android binding-project as an embedded reference JAR.
6. Add your binding to an Android App project, and try to build it. You'll probably get some build errors related to duplicate class inclusions. Remove these files from the directory created in 2 and repeat steps 4 & 5 until there are no such errors left.
7. Create/build your NuGet. You should now be able to successfully run the code contained in the partner SDK.

[deondk]

@philmarland that is great news! will the SDK work with xamarin.ios and xamarin.android as well?

[philmarland]

It's actually done in Xamarin.iOS and Xamarin.Android already. I misunderstood slightly before (it's a colleague doing the actual dev work). So from here our next step is wrapping the native bits into a forms project but he's confident that won't be a problem.

But yeah if you're looking to use the SDK to implement the UI in a Xamarin.iOS or Xamarin.Android app, this definitely appears to be a viable route.

[mattleibow]

@jpobst this might mean we need to add the viewbinding package to the next AndroidX release so people don't have to include it in their bindings.

[philmarland]

I got the impression from some other replies elsewhere that there was a stated intention not to do this because Xamarin Forms supports its own ViewBinding concepts. That didn't make complete sense to me. Certainly as a Xamarin user I'd like to see this better supported 'out of the box' because it seems increasingly likely to me that people will need to create custom bindings for SDKs / components that rely on this aspect of AndroidX.

[DevMo9x]

Any new progress regarding this?
@philmarland Did you end up publishing your repo somewhere? that would be helpful to the community and we can maybe consolidate the efforts going forward