stripe-android VS stripe

"I haven't seen excitement around any product and ecosystem launched since 2018 except flutter and Firebase."

Hard disagree, lol. Android Jetpack was launched in 2018. It was basically the second generation of Android development, it was a proper "tech stack" instead of everyone cobbling together third party libraries. Architectures switched over to the one true MVVM, instead of being this mess of MVC, MVP, etc.

Jetpack Compose is pretty amazing, it cut down our LOC by about half because we don't need adapters for every list. Kotlin coroutines & flow is nice. You get reactive programming, no more complex nested if/else conditions. We're not using Fragments or Activities much now either, navigation is via Compose, meaning DI is less necessary. So builds can be much faster too with a 2023 stack, and you can get UI changes rendered in the emulator immediately without even needing to update the build.

Here's a modern stack I made, should be able to spin up an app in an hour, and it shouldn't be too hard to read the code: https://github.com/smuzani/android-minimalist-template

Or if you want something production, Stripe's code is one of my favorites: https://github.com/stripe/stripe-android

Jetpack has some dark moments though, but that's a story for another day.

Ha! I hope not! You can look up my name as a maintainer in the android SDK here: https://github.com/stripe/stripe-android/blob/master/.github/CODEOWNERS and my linkedin here: https://www.linkedin.com/in/jaynewstrom/

Stripe Android SDK: Android SDK versions 20.7.0-20.11.0 were released this month and contain updates and fixes for functionality related to PaymentSheet and Identity.

Stripe Android SDK v20.6.2: Android SDK version 20.6.2 contains several bug fixes for Payments, reduces the size of StripeCardScan, and adds new rememberFinancialConnections features for Financial Connections.

Hi everyone - I'm on the Stripe Mobile SDK team and would love this community's feedback on what you would love to see us improve, namely in stripe-android. Would love to hear things that would make you say "Finally!", would have saved you several hours/days, or even little annoyances. No idea is too farfetched!

The Stripe Android SDK now supports SetupIntents with Google Pay. Use the multipayment UI to gain these features in v17.1.2.

Stripe Android SDK version 17.0.0 and 17.1.0: Android version 17.0.0 introduces GooglePayLauncher and GooglePayPaymentMethodLauncher to simplify Google Pay integration, and version 17.1.0 adds support for WeChat pay. Read more in the release notes.

Android SDK update: The latest version of the Stripe Android SDK (16.5.0) now supports Kotlin coroutines.

Thank you to our top open-source contributors this month: joeltaylor, ybiquitous, gogainda (stripe-ruby); masterjus (stripe-php); westy92, msternow (stripe-android); ees37 (stripe-go); Fonata (stripe-cli); rdsedmundo (stripe-node); hibariya (stripe-samples); risentveber, vinistock, jaredbeck, ryanwilsonperkin, anandvc, RyanBrushett, paracycle (sorbet).

Open-source 3DS2 SDK: We’ve open-sourced our 3DS2 SDK for iOS and Android under the MIT license.

New API version released: Version 2022-08-01 of the Stripe API has been released along with major version upgrades to all official client libraries, namely Dotnet, Go, Java, PHP, Node, Python, and Ruby. Read more about breaking changes in the API upgrades section and how to upgrade.

All I can give is my experience (been coding professionally for maybe 12-15 years) but I never looked at patterns like you are for a LONG time. I had no choice but to code in a "simple, straightforward" style because I didn't know anything fancy. I just did everything the normal, dumb way.

That said, things often become complicated because you don't have the skills to keep them simple (for example, you draw the boundaries between your modules wrong, or you fail to abstract the right things, leading to tight coupling and information leaking). So it's pretty normal for your software to be a mess for the first decade or so.

You should just keep writing your project, and as you find as the developer certain things on it are harder than they should be / frustrating / take too long, that will indicate a problem. Then you can keep trying to refactor until you get it right. Writing bad software is how you learn to write good software.

You asked for an example and I just gave you a bunch of philosophy, so I'll give you at least one. It depends on your language and what you're doing but I use Go a lot, and I think Stripe is pretty good at keeping things straightforward https://github.com/stripe/stripe-go

Unfortunately my experience has been different; I found that Stripe's Go doc doesn't match their API and while searching on it I found that someone else had mentioned that to their personnel over freenode 2 years ago.

So I raised an issue on GitHub[1] on Apr 9 and hasn't been attended to yet.

On a more serious note, Stripe's payment links doc seemed to imply that tax rates are automatically calculated if the tax rates are set(as we do with code when we pass the tax_id), But I found after couple of payments that tax aren't being charged, On conversing on Twitter with the payment links dev I came to realize that the required option was not there for me[2] and then after couple of hours with their support staff I was informed that the options was not available for India as 'Stripe Tax' is a separate product.

Overall, I'm happy with Stripe's tech; at least compared to the other options I have. But their docs have caused me some frustrations.

[1] https://github.com/stripe/stripe-go/issues/1447

[2] https://twitter.com/joshuaackerman/status/144759582096702259...

Stay compliant with updated KYC regulations: We’ve added future_requirements support to our Java, PHP, .NET, Go, and Node SDKs. This parameter enables developers to know account verification requirements and deadlines.

A nice feature of keeping the idempotency key separate from the payload is that a service like Stripe can build tools to help users with idempotency even if the user has no idea what an idempotency key is.

For example, take a look at stripe-go's implementation, which automatically tags a request with a key if the user didn't specify one:

https://github.com/stripe/stripe-go/blob/67034d2205c0240ade9...

This works for all mutating requests, and is useful because the built-in retry system will automatically reuse the same key that was generated. Users can get the benefits of idempotency without really having to understand very well what's going on under the hood.

I suppose you could still do that by munging each request body, but IMO it's a nice feature to make sure that requests are the same as what the user specified. Also note that in practice the implementations are probably not that wildly different under the hood — despite being in a header, Stripe's idempotency is still being handled by the same application stack which processes the payment (i.e. not a middle box or load balancer).

Stripe has seven main client libraries — Ruby, PHP, Python, Node, .NET, Go, and Java — and we wanted to give junior developers a foundation of broadly applicable knowledge to help them in all of their Stripe development going forward.

Thank you to our top open-source contributors this month: joeltaylor, ybiquitous, gogainda (stripe-ruby); masterjus (stripe-php); westy92, msternow (stripe-android); ees37 (stripe-go); Fonata (stripe-cli); rdsedmundo (stripe-node); hibariya (stripe-samples); risentveber, vinistock, jaredbeck, ryanwilsonperkin, anandvc, RyanBrushett, paracycle (sorbet).

Thank you to our top open-source contributors this month: merrickfox, bayandin (stripe-go); KaanOzkan, Morriar, RyanBrushett, sharpobject, paracycle, kddeisz (sorbet); hibariya, maeda-kazuya, (stripe-samples); jofftiquez (stripe-js).