[META] Roadmap to a consolidated Stripe module for Backdrop

[jenlampton]

How to make a consolidated Stripe module for Backdrop:

• [x] Create a new branch for active development (1.x-2.x)
• [x] Rename the code in the Stripe API module to simply "Stripe"
• [x] Rename the GitHub Repo to "Stripe"
• [x] Add an "upgrade path" from stripe_api to stripe

Include Features:

• [x] Webhooks integration
• [x] Global configuration of Stripe test/live API keys
• [ ] a new "Stripe Payment" form element type
• [ ] submodule for integration with Payment module
• [ ] Integrate between Drupal users and Stripe Customers.
• [ ] Add Rules Events fired when a customer is updated or created
• [ ] Token replacements for Customer ID, Default Source, and other properties.
• [ ] Views integration between User accounts and Customer fields
• [ ] hook_customer_stripe_info() allows other modules to add properties to Stripe Customer object during create/update
• [x] https://github.com/backdrop-contrib/stripe/issues/11 features from webform_stripe
• [ ] features from stripe_checkout

---

Original issue:

Hah, I just stumbled across your post on the webform_stripe module, here: https://www.drupal.org/node/2754019

was there any reason in particular you decided to go with stripe_api over webform_stripe? I wonder if I won't end up going down the same decision path you did :)

[laryn]

Well, long story and it would be good to have another person's input, actually.

I started off wanting to build a simple module as a learning project that allowed nonprofits to quickly/simply create a donation block that they could place on a layout. Sort of a drop-in Stripe replacement for the way a lot of small orgs use Paypal donate buttons.

Then I also came across webform_stripe and really liked the sound of that. There was a thread in there about potentially merging functionality with Stripe API to reduce duplication of effort that made sense (and I also didn't want multiple modules bundling Stripe's library separately) so I ported Stripe API.

My simple Stripe Checkout donate block module then listed Stripe API as a dependency to ensure Stripe's library was included. When I looked at the webform_stripe module, it was also a Stripe Checkout solution so I decided to rework it into a submodule of Stripe Checkout with a Stripe API and a Stripe Checkout dependency (again as an attempt to prevent duplicative admin panels -- e.g. a Stripe Checkout admin page for my initial module, then a separate one for the webform functionality), and it's very close to working. I ran into one issue that made me begin to second guess that decision and wonder if I should have just left it alone as webform_stripe (at least the name, even if it was still a submodule of Stripe Checkout).

Anyway, take a look. I'm open to feedback and changes!

https://github.com/backdrop-contrib/stripe_checkout

(The webform_stripe functionality is not in the official release since it's not fully working yet).

[jenlampton]

From an end-user perspective, having a separate module for everything seems burdensome. If I use Stripe for my non-profit (and I do), I don't want to have to install one module to use it with webforms, one for a donation block, and maybe another one for some kind of a shopping cart / checkout solution.

Ideally, I'd install the "Stripe" module, and it would provide all those things - or not - depending on what else I had installed. I would love to see the most common things included in the base module (the one that includes the library) rather than it being only an API module that does nothing for the user, on it's own.

There should obviously be some limits, just look at all the stripe modules that exist for Drupal:

• Stripe Usage: 143
• Stripe API Usage: 95
• Webform Stripe and Stripe Webform Usage: 183
• Stripe Field Usage: 7
• Stripe checkout Usage: 37
• Register with Stripe and Stripe registration Usage: 0
• Stripe Subscription Usage: 43
• Commerce Stripe Usage: 3,055
• Stripe Payment Usage: 47
• Ubercart Stripe Usage: 337
• CiviCRM Stripe Usage: 14
• ... there's so many more, I'm going to stop here.

If we could get to the same 80% mark as core, where the minority of sites using the Stripe module would also have to add additional supporting modules, I think that is what would make me most happy.

How would you feel about moving in this direction? If I were to provide a PR that added webform support to the stripe_api module would you consider that for inclusion?

Or maybe more importantly, how would you feel about about a namespace change? "Stripe API" becomes "Stripe"? We could look at what the Drupal Stripe module provides, be sure to include those features too, and then make sure there's an upgrade path.

[laryn]

Having fewer modules to track down and download was the point of bundling the webform functionality into stripe_checkout (albeit as a bundled module). The extra click to activate the module didn't seem too onerous given that some may not need the webform functionality. But I'm definitely open to tightening a step further so all of the stripe_checkout functionality gets into the main stripe module (and I'm fine with calling it stripe instead of stripe_api -- there's nothing preventing another module from using it as an API module if they want to).

Short form: I'm very open to modifying this, especially if you are providing a PR. :) In fact, if you are interested, I'd be fine with you co-maintaining.

[jenlampton]

That sounds like a plan! :) And yes please, and thank you!

[laryn]

You're very welcome. And you're officially a maintainer now, thank you for working together on it!

[jenlampton]

I've just completed the "Stripe payment" webform component, and committed it to the 2.x branch. I'm going to test it over the next few weeks before I make an official release, but so far so good!

[laryn]

@jenlampton Awesome! 👍