nehero
Bling gives you all of the tools needed to add recurring subscriptions with Stripe to your Phoenix applications.
It includes:
- Ecto schemas for customers and subscriptions
- Use any existing ecto schema like User or Team as a customer
- Saving default payment methods to customers
- Creating subscriptions
- Multiple subscriptions per customer
- Subscription quantities
- Failed payment resolution page
- + lots more! See the full list in the hexdocs readme
When I was working with Laravel every day we made extensive use of the Laravel Cashier package. I had been missing it while working on elixir products, so I decided to bring it over 
hexdocs:
github:
https://github.com/ozziexsh/bling
There’s a few things I want to add to it before pushing v1.0 such as metered billing and one-off charges, but it has most subscription functionality ready to go.
Forewarning the readme contains a link to a paid product that provides a complete UI on top of Bling, but Bling itself is open source and free to use as a headless subscription manager
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
nehero
Thanks! I believe I needed it because of controller/html files
I’m sure there is a way to render these without depending on liveview, but it was the easiest route to take for the initial release
f0rest8
This is awesome. Initial question, is there a particular reason it’s dependent on LiveView 0.18?
stocks29
Very cool project!
I’m attempting to add it to my ash project but running into an issue. The preloads don’t work with ash because the type of missing preload fields is
Ash.NotLoadedinstead of the corresponding ecto struct. Maybe there is a way to externalize the preloading operation so someone can optionally plug in their own preload function, defaulting torepo.preloadas is the case now.A nice-to-have would be to allow for separation of the application’s user and local stripe customer records so each of these records can live in different contexts/domains and not require fetching the billing info (stripe_id, etc..) when it’s not needed. I tried to achieve this but ran into an issue because the updates to the user record require the fields to be on the same schema as the customer’s email address.
Looking forward to continued development on this project!
Edit: I was able to work around the first issue by implementing a proxy
Repomodule which is implemented by calling ash and providing this proxy repo to bling instead of the underlying ecto repo module.