[Proposal] Add official Stripe Terraform provider support alongside community provider

[giorgionocera]

Context & Problem

SST v4 currently uses pulumi-stripe, which bridges the community-maintained lukasaron/terraform-provider-stripe provider. While this provider has been reliable, it's missing some critical features that are now available in Stripe's ecosystem.

Most notably, it lacks support for eventDestination, which is used for natively routing Stripe events directly into AWS EventBridge. This allows routing Stripe events natively to EventBridge, eliminating the need for custom webhook endpoints and handlers.

Recent Development

Stripe recently released their official Terraform provider (stripe/terraform-provider-stripe), which:

• Supports eventDestination and EventBridge integration
• Is actively maintained by Stripe (it's under their GitHub organization)
• Includes support for newer Stripe API features

Proposed Solution

Add the official stripe/terraform-provider-stripe as a new bridged provider in SST, keeping the existing community provider intact.

Approach:

• Introduce the official provider under a distinct name (e.g., stripe-official)
• Leave current stripe provider (community) unchanged for backward compatibility

Why keep both:
Replacing the existing provider would (probably) break production deployments. Coexistence gives users time to migrate on their own schedule.

Implementation

I'm happy to contribute a PR to anomalyco/provider to bridge the official Stripe provider. Before starting, I'd love feedback on the naming preference: stripe-official, stripe-v2, or another convention?

References

• Official Stripe Terraform Provider: https://github.com/stripe/terraform-provider-stripe
• AWS + Stripe EventBridge announcement: AWS blog post on Stripe integration
• Related (closed) PR Add Stripe #61: Version bump for community provider (not introducing official provider)

Looking forward to your feedback! 🙏

[giorgionocera]

Hey team! 👋

I know the naming is the tricky part here.
To make the decision easier, let me break down 3 possible approaches with their trade-offs:

Option 1: Dual providers (stripe + stripe-official)

• Keep existing stripe (community provider) as-is
• Add new stripe-official (Stripe's official provider)
• Users explicitly choose which to use in their code

Pros:

• ✅ Zero breaking changes for existing users
• ✅ Easy migration path (users can test new provider alongside old one)
• ✅ Can ship immediately

Cons:

• ❌ Potential confusion about which provider to use
• ❌ Maintaining two providers long-term

---

Option 2: Replace with deprecation period

• Replace stripe with official provider in next major version
• Keep old provider available as stripe-legacy for 6-12 months with deprecation warnings
• Update docs to guide migration

Pros:

• ✅ Clean long-term solution
• ✅ Clear direction for users (one blessed provider)
• ✅ Community provider still accessible during transition

Cons:

• ❌ Requires communication & migration effort
• ❌ Breaking change (needs major version bump)

---

Option 3: Namespace by version (stripe-community, stripe-official)

• Explicitly name both providers based on their origin
• Let users choose based on their needs

Pros:

• ✅ Crystal clear naming semantics
• ✅ No confusion about which is which

Cons:

• ❌ Renaming the existing provider might be awkward
• ❌ "Community" sounds less trustworthy (even if it works fine)

---

My recommendation: Option 1 for now

Start with dual providers (stripe + stripe-official) to avoid disruption. Once the official provider proves stable and the EventBridge integration becomes essential for more users, we can deprecate the old one gracefully.

Next steps:

The code is ready - I've already implemented Option 1 in PR #85. The bridging is straightforward and can be merged once we align on the naming approach.

What do you think? Happy to go with whatever you prefer!

[dragonautdev]

I agree option 1 sounds like the best to prevent sudden outages for existing users of the community package.

[giorgionocera]

Hi there! 👋

I've opened PR #85 implementing the stripe-official provider as discussed.

Changes:

• Added stripe-official alongside existing stripe provider (zero breaking changes)
• Uses version 0.2.0 (latest from Stripe)

The PR is ready for review. Let me know if you need any changes!