garymoon

[tawdry crescent]

Do you have specific examples of code snippets that are not working as intended?

[tough thorn]

I didn't say or imply that any of them weren't working as intended?

[tawdry crescent]

The code is all over the place, they're definitely not current (specifically around payment element vs card element)
I assumed you meant that the snippets weren't working based on the above quote. If that's not the case, can you expand a little bit?

To be clear, I think this is really valuable feedback and I'd like to raise it in the proper internal channel, but I need to make sure I understand what improvements specifically you think would be valuable.

[cold ember]

Hey again @tough thorn

This is something we think about a lot. One challenge, similar to the docs/guides, is that its not practical to implement every permutation of features and use cases, so we try to focus on common ones.

I'm happy to share the general feedback, but if you have any specifically painful examples that frustrated you while working, I can additionally share that to see if we can make more specific improvements.

[tough thorn]

It's less that there's missing use-cases, and more that as I said the existing use-cases aren't of comparable quality to the SDKs and documentation.

Some broad examples:

• The CSS included in most of the examples is from scratch, rather than using something that uses broadly familiar semantic classes (an obvious example would be Boostrap).
• Most of the samples are creating card elements where they ought to be using payment elements (I couldn't find a sample using the payment element with subscriptions for example, and went down the rabbit hole of wading through hundreds of lines of javascript where with the payment element < 100 is enough).
• There are separate repos for various use cases, but it's unclear how they're deliniated (how does one decide between checkout-single-subscription or subscription-use-cases for example).
• For documentation purposes it would be much easier to follow the flow in the backend language of choice with post requests and server-side page rendering, but instead there's hundreds of lines of javascript manipulating forms on the client side.

At a 30k-foot-view these kinds of naggles combine to create the impression of a hodge-podge that's difficult to navigate. In my case (and this could certainly be a me-problem, but I can only provide feedback from my perspective) I ended up spending a lot of time going down the wrong path (card element vs payment element) that I might not have were things more clearly laid out.

(please don't take any of this as hostile or anything of the kind, I'm just in a hurry to finish my integration and picked a poor time to submit feedback 😟 )

Thanks for unlocking the thread and your interest in the feedback 💙 I'm very happy to share/discuss further, I'm just in a hurry at this moment is all.

[cold ember]

THat's all very fair criticism, and to be honest I've struggled at times with the same. I'm going to pass this along internally to be people focused on this. Really good perspective to share, especially when looking through multiple repos and comparing.

Thanks for taking the time to share all this ❤️

[tough thorn]

Thanks very much 🙂

[cold ember]

Do you want to share your stripe account ID for me to associate with the feedback?

It would give us an opportunity to reach out to you later

(completely optional)

[tough thorn]

May I DM you my email address instead? I'm not the primary contact on the account, just the engineer writing the implementation.

[cold ember]

Sure