Anyone know of a KMM wrapper lib around the Stripe...

# multiplatform

[chrisjenx]

Anyone know of a KMM wrapper lib around the Stripe API's? Trying to avoid writing my own lol

[Chrimaeon]

1. https://klibs.io/?query=Stripe
2. https://blog.jetbrains.com/kotlin/2023/07/update-on-the-name-of-kotlin-multiplatform/

[chrisjenx]

Did not know about klibs thats cool

[markturnip]

what you end up doing @chrisjenx ?

[markturnip]

I’m not sure about that open source Stripe sdk. Particularly since it doesn’t seem to have the Stripe UI baked in.

[markturnip]

I’m thinking of building a wrapper around the two native SDK’s myself too!

[chrisjenx]

Yeah basically did that, for WasmJs, iOS and Android

[chrisjenx]

For the WasmJs you need to make sure the js lib gets attached to the root dom, not the compose one, as stripe stupidly doesn't support shadow doms (not like basically every spa uses those.. but hey)

[chrisjenx]

THen you can use LocalViewController and LocalContext for the iOS and Android libraries respectively. Using Franks SPM is hugely helpful

[markturnip]

Do you mean François?

[chrisjenx]

yes

[markturnip]

Ah not so concerned with WasmJs. I’m surprised someone hasn’t already put together a module which imports both platform dependency - with ios using spm4kmp

[markturnip]

Anyway only need something relatively simple for my use case to begin with. So will have a go next week

[chrisjenx]

Yeah, I only use the PaymentLauncher, which unless you're doing something odd handles pretty much adding payment methods and paying

[markturnip]

Great!

[markturnip]

Hey! Struggled a bit here, I thought I may be able to instantiate the Android sourceset PaymentSheet from within my definition, but the initialiser requires Activity

For now I’ve ended up creating a StripeCheckout composable which owns the paymentSheet and is responsible for presenting:
https://github.com/markst/stripe-kmp/blob/main/shared/src/androidMain/kotlin/com/fouroneone/stripe/StripePayments.android.kt

[markturnip]

I thought I was going to be able to build the PaymentSheet simply like this:

private class AndroidStripePayments(private val context: Context) : StripePayments {

    var paymentSheet: PaymentSheet?

    @Composable
    override fun Initialize(publishableKey: String) {
        PaymentConfiguration.init(context = context, publishableKey = publishableKey)
        paymentSheet = PaymentSheet.Builder { result -> onResult(result.toCommonResult()) }.build()
    }

    @Composable
    override fun presentWithPaymentIntent(
        clientSecret: String,
        onResult: (PaymentSheetResult) -> Unit
    ) {
        paymentSheet.presentWithPaymentIntent(
            paymentIntentClientSecret = clientSecret,
            configuration = null
        )
    }
}

[markturnip]

Think I’ve settled on the fact I have to use Composable for my PaymentSheet.

@Composable
actual fun rememberPaymentSheet(
    stripePayments: StripePayments,
    onResult: (PaymentSheetResult) -> Unit
): PaymentSheetWrapper {
    val paymentSheet = remember(onResult) {
        PaymentSheet.Builder(resultCallback = { result: StripePaymentSheetResult ->
            onResult(result.toCommonResult())
        })
    }.build()

    return remember(paymentSheet) {
        AndroidPaymentSheetWrapper(paymentSheet)
    }
}

But am curious how you went about this @chrisjenx

[chrisjenx]

I'm traveling right now ping me next week and I'll copy paste my implementations

[markturnip]

Ping

[markturnip]

Would be hugely grateful @chrisjenx

[chrisjenx]

Ahh yes

[chrisjenx]

Lemme get Junie to create a .md for you

[chrisjenx]

Haven't forgotten, was finishing another task

[markturnip]

no stress at all!

[markturnip]

it’s the middle of the night for you

[chrisjenx]

I noticed I forgot to finish payment Intent for wasm so glad I check this!

[chrisjenx]

Lemme know if there's anything else you want to elaborate on

[markturnip]

Awesome! Thanks so much for taking the time to do that

[markturnip]

Interesting so you’re passing the the activity to AndroidPaymentsLauncher() I had trouble with that:

IllegalStateException: LifecycleOwners must call register before they are STARTED

[chrisjenx]

override fun onCreate(savedInstanceState: Bundle?) {
        enableEdgeToEdge(statusBarStyle = SystemBarStyle.light(Color.TRANSPARENT, Color.BLACK))
        super.onCreate(savedInstanceState)
        // Always create the root component outside Compose on the main thread
        val defaultComponentContext = defaultComponentContext()
        val root = DefaultAppComponent(
            componentContext = defaultComponentContext,
            navigationHandler = AndroidNavigationHandler(this),
            paymentsLauncher = AndroidPaymentsLauncher(this),
        )

[chrisjenx]

I think I remember that being an issue, I was using LocalContext and used to init from the @Composable, but paymentsheet needed to be registered in onCreate because the activity result they use needs to be able to listen to ActivityResults from there started activity. Just annoying API design on Stripe side (Also would be nice if google result handler would just send you the result after registering so you can register post onCreate)

[chrisjenx]

FYI Stripe SPM is buggy and somtimes misses assets (probably an SPM bug, but Stripe refuses to fix it), I had to resort to Stripe being imported manually, created a gist incase you need to do the same:

https://gist.github.com/chrisjenx/79fe87fc45a3821afe2715832e3770be

[markturnip]

Yeah had noticed. Strange one that it only seems to occur sometimes, I assumed it was because I was using spm4kmp

[chrisjenx]

Nope, I used SPM directly in Xcode, same issue. As far as I can tell it's cause SPM is non-derministic so it runs in different orders every time it imports and seems Stripes modules might overwrite each other, very strange. There's a bunch of tickets on their iOS repo they close without a fix.
Guess Pod's is still better at some stuff...

[markturnip]

right. thanks for letting me know!