XDev.Jakewharton.Disklrucache 2.0.2.1

XDev.Stripe.PaymentSheets

A .NET Wrapper for the Stripe PaymentSheets SDK for iOS + Android.

Latest release <a href="https://www.nuget.org/packages/XDev.Stripe.PaymentSheets"> <img src="https://img.shields.io/nuget/v/XDev.Stripe.PaymentSheets"></a>

Latest build    <a href="https://www.nuget.org/packages/XDev.Stripe.PaymentSheets"> <img src="https://img.shields.io/nuget/vpre/XDev.Stripe.PaymentSheets"></a>

<br>

source repo

Native SDK Versions

Android binding structure

XDev.Stripe.Android <a href="https://www.nuget.org/packages/XDev.Stripe.Android"> <img src="https://img.shields.io/nuget/v/XDev.Stripe.Android"></a>

The Stripe Android SDK is bound by a single project, Library/Android/XDev.Stripe.Android, which rolls up all 12 com.stripe Maven artifacts required by PaymentSheet (paymentsheet, payments-core, payments-model, payments-ui-core, stripe-core, stripe-ui-core, stripe-android, attestation, financial-connections-core, financial-connections-lite, hcaptcha, stripe-3ds2-android).

This replaces the 12 separate binding projects/packages that preceded it. The old XDev.Stripe.Binding.Android.*, XDev.Stripe.Attestation, XDev.Stripe.FinancialConnections*, XDev.Stripe.HCaptcha and XDev.Stripe.Stripe3ds2Android package IDs are retired and no longer published — they were always implementation detail. The supported surface is the meta-package XDev.Stripe.PaymentSheets and the wrapper XDev.Stripe.PaymentSheet.Android.

Updating the Stripe version

All 12 com.stripe artifacts ship from Stripe's monorepo on one release train at one version — verified against Maven Central across all 73 releases at or above 21.7.0. So the whole SDK moves from a single version knob:

<PropertyGroup Label="com.stripe">
  <paymentsheet>22.6.1</paymentsheet>
</PropertyGroup>

The PropertyGroup Label must equal the Maven groupId and the child element name must equal the artifactId, exactly. That convention is what lets the Build.Update "pack-bot" in XDev.Jetbrains.InteropLibs poll Maven Central and bump this repo unattended; it rewrites that one element plus [Release Version] in Library/Android/XDev.Stripe.Android/BuildInfo.txt. Keep the two in sync when editing by hand.

<PackageTags> in the same csproj carries artifact= / artifact_versioned= entries for every packed Maven coordinate. These are load-bearing, not SEO: a consuming app's Java dependency verifier (XA4241) reads them from the nuspec.

AndroidX Navigation is held at 2.8.x on purpose

Every Android project targets net9.0-android35.0 only, and Xamarin.AndroidX.Navigation.Compose is deliberately held at 2.8.9.2 — the pre-KMP-split generation. Do not raise it casually; both directions have been measured.

At 2.9.x the Navigation family went KMP-split: Common/Compose/Runtime became ~16 KB type-forwarding facades over new .Android siblings, while Fragment/UI stayed real assemblies. Mixing generations breaks GenerateJavaStubs in the consuming app — it cannot walk a base-type chain from a real 2.8.x assembly through a 2.9.x facade, so it reports the type as having no Java.Lang.Object ancestor (XA4212).

The two consumer generations want opposite things:

• .NET 9 consumers cannot use 2.9.x at all. Android SDK 35's stub generator crashes outright with XAGJS7000 (a NullReferenceException) on the facades, regardless of version skew.
• .NET 10 consumers need 2.9.2.1, because MAUI 10 supplies Common/Runtime/Fragment/UI at that version and a 2.8.x Compose floor becomes the straggler.

Since the Demo app here is the .NET 9 end-to-end test, 2.8.9.2 is the only value that keeps the repo building.

Consequence for .NET 10 consumers: pin Xamarin.AndroidX.Navigation.Compose to 2.9.2.1 at your app head until this package moves to a .NET 10 target framework.

<PackageReference Include="Xamarin.AndroidX.Navigation.Compose" Version="2.9.2.1" />

When this repo does move to net10, the AndroidX versions go up as a set — they cascade from one cause: Navigation.Compose/Fragment/UI 2.9.2.1, then AppCompat >= 1.7.1.1 and Material >= 1.12.0.5 (required by Navigation.UI), then ConstraintLayout >= 2.2.1.3 and RecyclerView >= 1.4.0.3 (required by Material). Each is the exact floor; pinning lower is an NU1605 downgrade. The XDev.Stripe.Android.csproj comment carries the same list.

net8.0-android is not an option going forward: Android SDK 36 raises NETSDK1202 for framework version ≤ 8.0 with WarningsAsErrors.

Java dependency verification is in-box

This repo no longer references XDev.Android.MavenBinding.Tasks (the jpobst/Prototype.Android.MavenBindings prototype). The .Net SDK took the feature in-box at 35.0.50, and running both double-injects @(AndroidLibrary). If you are porting an older binding project, the vocabulary changes are:

AndroidMavenLibrary items need no change — the SDK understands them natively. Note also that a dependency satisfied by a PackageReference must not also be listed as ignored; doing both throws XAJDV7004 ("An item with the same key has already been added").

When a native SDK leaks a compile-time-only artifact into its POM as a runtime dependency, prefer an AndroidIgnoredJavaDependency over wrapping it in a binding package. dev.drewhamilton.poko:poko-annotations is the worked example here: Stripe declares it in payments-core / payments-model, and Poko generates equals/hashCode/toString at Kotlin compile time, so the annotation only ever reaches the binding generator's classpath — it appears in obj/**/generated/src/generator.rsp, but is never needed at runtime, only the code it generates.

Introduction

This is a .Net Wrapper for the Stripe-PaymentSheets SDK for iOS + Android. It provides a simple and easy-to-use interface for integrating Stripe's payment processing capabilities into your .NET applications. With this wrapper, you can easily create and manage payment sheets, handle payments, and access various features of the Stripe API without having to write platform-specific code.

Getting Started

For security reasons, the Stripe API keys are not included in this repository. To use this wrapper, you will need to obtain your own Stripe API keys from the Stripe Dashboard. Once you have your API keys, you can set them up this repo's test application as follows:

in the appsettings.json file in your local repo-path (note DO NOT commit this, PRs with this file will be rejected):

{
  "AppSettings":
  {  //this could be injected from secure file or environment variable in production build
	"StripePublishableKey": "pk_test_your-publishable-key", 
	// this should only be used by a back-end server in production builds.
	// an app should call your back-end server to create payment-intents 
	// and handle payments instead of directly
	// using a secret key because this key can be easily compromised if 
	// included in a mobile application installed on user-devices.
	// key here is only for testing purposes ONLY without back-end server
	"StripeSecretKey":"sk_test_your-secret-key" 
	}
}

Build and Test

.NET SDK 9 builds this entire repo. One global.json at the root pins it, and one android workload band (9.0.100) covers everything:

dotnet workload install android ios
dotnet build Maui.Stripe.PaymentSheet.sln

Nothing here needs .NET 10, and there are deliberately no per-directory global.json files. That matters more than it sounds: SDK selection is per dotnet invocation, resolved by walking up from the current working directory, and it applies to the whole build graph including ProjectReferences — so a global.json in a subdirectory only takes effect if you cd there and build standalone. A single root file avoids that trap entirely.

Two things that will bite if changed carelessly:

• global.json must name a full three-part version. A two-part value such as "9.0" is not a valid selector, is silently ignored, and falls through to the newest installed SDK. That is how this repo once ended up building on .NET 10 without anyone asking it to.
• Moving to SDK 10 is not a drop-in. SDK 10 cannot build net8.0-ios at all — its iOS workload manifest has no framework-version 8.0 branch, so net8 falls into the VersionLessThan 9.0 path and imports Sdk-eol.props, an EOL stub rather than a working SDK (it forces TargetPlatformVersion to 1.0 and promotes NETSDK1202 to an error on purpose). SDK 10 also cannot build net8.0-android. So an SDK 10 move requires retargeting iOS first — see the Navigation section above for the Android half of that story.

If you hit NU1202, check dotnet --version and dotnet workload list from the directory you are building in before anything else.

Third-party bindings under Library/XDev.Droid

Three non-Stripe bindings live here and are staged to move to XDev.Jetbrains.InteropLibs, to be consumed from this repo by PackageReference instead of ProjectReference: com.google.pay.button:compose-pay-button, com.google.android.instantapps:instantapps and com.jakewharton:disklrucache.

They are single-TFM net9.0-android35.0 on purpose — pure AAR repackaging with no generated managed API, and net9 is buildable by both SDK 9 and SDK 10 whereas net8.0-android is buildable by neither that matters. Each now carries a labeled version knob plus artifact= / artifact_versioned= PackageTags, which is what lets a consumer's Java dependency verifier accept them as a PackageReference — without those tags the swap fails XA4241.

Platform support for development

• Android bindings: build on Windows, macOS, or Linux.

• iOS bindings: macOS only. The .NET iOS SDK requires Xcode (macOS). Additionally, the Stripe xcframeworks vendored under Library/iOS/Stripe.Binding.iOS.PaymentSheet/Frameworks/ contain file paths that exceed Windows' default 260-character MAX_PATH limit. On Windows, a clone will appear to have ~100 "deleted" files under the maccatalyst and simulator slices (the files in git's index simply could not be checked out by the OS). This is a display artifact only; it has no effect on CI or macOS builds. Do not commit the "deletions" from a Windows machine — it will break the package on consumer link.

  CI packs this package on macOS agents, where all files check out cleanly and dotnet build -c Release bundles every xcframework into the nupkg.

Contribute

Yes please! Contributions are welcome. If you have any suggestions or improvements, please feel free to submit a pull request or open an issue.