Stripe Integration in .NET MAUI: Bindings for iOS and Android

When I first needed Stripe integration in a .NET MAUI project, I went looking for existing solutions. I did find some libraries — but they were outdated, incomplete, and not maintained. None of them worked with the latest versions of Stripe's SDKs and latest version of MAUI.

So I decided to build my own.

That's how G1.Stripe.Maui was born: a modern, open-source library that brings Stripe's PaymentSheet to .NET MAUI apps on both Android and iOS.

Step 1: Android — The Easy Part

.NET has pretty good tooling for Android bindings. I used the built-in Xamarin/MAUI binding tools to generate wrappers around the Stripe Android SDK.

The biggest pain? Maven dependencies.

Linking the correct versions, resolving conflicts, and getting everything to compile took far longer than it should have. But once the dependencies were sorted, the binding itself was straightforward.

At this point, I thought the hard part was behind me. I was wrong.

Step 2: iOS — The Nightmare

On iOS, I discovered the real challenge. Stripe's SDK is written in Swift, and .NET cannot consume Swift APIs directly.

That meant I had to:

Write Swift wrappers, exposing the required APIs to Objective-C (using @objc), since only Objective-C is consumable by .NET.
Run Sharpie to generate C# definitions from those Objective-C headers.

But here's the catch: Sharpie has become proprietary and only old versions are still available. They're buggy, outdated, and not really supported anymore.

At one point, I even started writing my own syntax analyzer for iOS frameworks to replace Sharpie. I didn't finish it — partly because this was just a small part of my job, and partly because I was already exhausted.

To put it simply:

Android bindings → easy.
Cross-platform abstractions → easy.
iOS bindings → pure pain.

Step 3: Cross-Platform Abstraction

Once both bindings existed, creating the cross-platform abstraction was simple.

My goal was to design a clean C# API that feels natural for .NET developers. Instead of worrying about iOS vs Android differences, you can just use a single interface.

var paymentSheet = App.Current.Services
    .GetRequiredService<IPaymentSheet>();
 
paymentSheet.Initialize("pk_test_XXXXXXXXXXXXXXXXXXXX");
 
var result = await paymentSheet.Open(options, cancellationToken);
 
switch (result)
{
    case PaymentSheetResult.Completed:
        // Payment succeeded
        break;
    case PaymentSheetResult.Canceled:
        // User canceled
        break;
    case PaymentSheetResult.Failed failure:
        // Something went wrong
        break;
}

That's it. A unified Stripe PaymentSheet experience in .NET MAUI.

Challenges and Lessons Learned

Existing Stripe integrations for .NET were too outdated to use.
On Android, Maven dependency hell was the biggest issue, but solvable.
On iOS, bridging Swift → Objective-C → C# was the true nightmare.
Sharpie being proprietary and outdated made things worse. At some point, I nearly built my own replacement tool.
Once bindings were in place, the abstraction layer was straightforward.

What's Next

G1.Stripe.Maui is already on NuGet, but there's more to do:

Broaden iOS API coverage.
Improve documentation and add sample apps.
Encourage community contributions.

Conclusion

G1.Stripe.Maui exists because the available Stripe integrations for .NET MAUI were outdated and unusable.

Android was fine. Abstractions were easy. But iOS — with Swift wrappers, Objective-C exposure, and outdated Sharpie — nearly broke me.

And here's the twist: after finishing all of this work, we changed framework. I don't even need this library anymore.

But if you do, it's here for you.

Beyond Stripe: more than one library

G1.Stripe.Maui is just one part of what we do. At Generation One, we maintain a portfolio of open-source libraries and infrastructure tools, designed to empower developers across platforms.

If any of these modules catch your interest, feel free to explore our GitHub organization: Generation-One.

We aim for openness, extensibility, and community contributions across all our projects.