HackerTrans
TopNewTrendsCommentsPastAskShowJobs

brunosutic

no profile record

Submissions

Knock-to-Unlock Stripe integration vulnerability

railsbilling.com
1 points·by brunosutic·6개월 전·0 comments

Friendly attributes pattern in Ruby

brunosutic.com
101 points·by brunosutic·8개월 전·75 comments

Friendly Attributes Pattern in Ruby

brunosutic.com
2 points·by brunosutic·8개월 전·0 comments

comments

brunosutic
·3개월 전·discuss
Hetzner
brunosutic
·4개월 전·discuss
I tried lnav about 7-8 years ago and as a terminal junkie I really liked the features.

The only breaking thing was a huge (almost bloated) memory consumption. At that time lnav basically just kept everything in memory. Does anyone did that change?
brunosutic
·7개월 전·discuss
RailsBilling - Stripe subscriptions for Rails app in one command.

Killer feature is multiple plans per customer.

https://railsbilling.com
brunosutic
·8개월 전·discuss
How do you guys handle past due / grace period if there are no webhooks? Like, do you notify the end-user that their card failed and they need to update their card? Or do you let Stripe send emails?

What's your approach to 3DS and related race-conditions for subscriptions? In my experience 3DS is by far the biggest problem for subscription integrations - not the webhooks.
brunosutic
·8개월 전·discuss
> The DX of Stripe is already great

This used to be the case back in 2015, but not anymore. The financial compliance is more strict now. You have to charge taxes. EU enforced SCA / 3DS in 2019. All of these are hard to implement (correctly) on their own - almost impossible together.

Source: I run (paid) Ruby on Rails library for Stripe subscriptions integrations. I also do billing audits. Here's an example audit where I pay $30, get ~$2000 https://www.youtube.com/watch?v=YuXp7V4nanU
brunosutic
·8개월 전·discuss
Article author here - thank you for putting it this way. This is exactly the attitude I wanted to convey: it's something I tried and really liked for this specific use case. I shared because I hope it might inspire others.

"Friendly Attributes" is not the "new way", not to be used "everywhere now", does not "apply to all scenarios".

If you like it, maybe you'll use it once in the next five years when the opportunity arises.
brunosutic
·8개월 전·discuss
Your input would work exactly as you wrote it if passed to `Billing::Plan.find_or_create_all_by_attrs!`, just add commas at the end of lines.

If you want to make it even shorter, you have a few options - it really just comes down to preference:

  # Option 1. my personal favorite, follows structure of
  # intervals and plans on a pricing page.
  1.month => {red: 10, blue: 120},
  1.year => {red: 120, blue: 300}

  # Option 2. this is fine too
  red: {1.month => 10, 1.year => 120},
  blue: {1.month => 120, 1.year => 300}

  # Option 3. possible and works, but hurts my brain, NOT recommended
  10 => {red: 1.month},
  120 => {red: 1.year, blue: 1.month},
  300 => {blue: 1.year}
> there is always at least one attribute that serves as a "discriminator" between the billing plans, right

Just a note: if you try to create two plans with the same attributes, that would error because of ActiveRecord uniqueness validations (and DB constraints). No point in having multiple identical plans.
brunosutic
·8개월 전·discuss
This is supported and would work with no implementation changes. The "Friendly Attributes" idea is very flexible.

Just a small Ruby syntax correction for your example:

  Billing::Plan.find_or_create_all_by_attrs!(
    standard: {1.month => 10, 1.year => 100},
    ...
  )
brunosutic
·8개월 전·discuss
> I would consider monthly Enterprise & yearly Enterprise the same plan, with modified cost & billing frequency.

How would you then call the objects that store costs and billing frequency? :)

Here's what Stripe uses:

- Product: "describes the goods or services". This is where you define a (plan) name and features.

- Price: defines the amount, currency, and (optional) billing interval. Since interval is optional, Prices can be used to define both recurring, and one-off purchases.

Technically, using Prices for recurring, and one-off payments is a brilliant idea. The problem is, no one refers to recurring payments as "prices". Everyone calls a "$50 per year" option a "plan".
brunosutic
·8개월 전·discuss
That link describes billing problems of a neobank... I mean, yes, there's a big gap between my test helpers and financial institution's problems - to the point it's not related at all.

But, in principle I agree billing, even the simple SaaS stuff, is much harder than most people expect it to be in 2025. My product (linked in the original article) is based completely on Stripe Billing - and it is still very hard to avoid all the footguns.

For people wondering, I even have an example how wrong it can go: I "audited" a successful SaaS I know uses custom Stripe billing. I paid $30 for a starter plan, but was able to "upgrade" to $2k plain for free. Here's the full video: https://www.youtube.com/watch?v=YuXp7V4nanU
brunosutic
·8개월 전·discuss
Hi, I'm the author of the article and the software library. I confirm I actually do use the examples from the article in my code.

Here's the example that runs in hundreds of integration tests:

  expect(billing_pricing_plans).to eq billing_plans(
    1.month => [:free, :premium, :pro, :enterprise],
    1.year => [:free, :premium, :pro, :enterprise]
  )
It asserts what plans the customers see on the pricing page.
brunosutic
·8개월 전·discuss
The usual response to this complaint in the Ruby/Rails community is that optimizing for nanoseconds, or even milliseconds doesn't matter when the same operation also involves multiple database queries or API calls.

Let's take this example from the article:

  Billing::Plan.find_or_create_all_by_attrs!(
    1.month => {standard: 10, pro: 50, enterprise: 100},
    1.year => {standard: 100, pro: 500, enterprise: 1000}
  )
This ensures six billing plans are created. That means 6 DB queries and 6 Stripe API queries, at a minimum.
brunosutic
·9개월 전·discuss
Nice to see product from Zagreb! The link is for the /login page which tells us nothing about the product. Next time post a link to your home page.

Nice work btw. The landing page is pretty and I like the pricing slider :)
brunosutic
·9개월 전·discuss
We have 3 young kids in the range from 2 to 5 years old. We use white noise heavily for our kids sleep. It isolates them from the noises we make around the house.

For this purpose I recommend "LectroFan" devices. We have like 5 "LectroFan Evos" in our's and our kids' bedrooms. They just work, no apps, no upgrades, no LEDs blinking, and thank god, no screens. These devices are worth their amount in gold.

On the phone I recommend using iOS built-in white noise feature. We use it when travelling by car, and our kids sleep in their seats. When we turn the white noise on they stop talking and it quickly lulls them into sleep.
brunosutic
·9개월 전·discuss
Yes, and the same feature is available on Mac too. I occasionally use it with headphones for work, when I want to stay focused.
brunosutic
·9개월 전·discuss
Does anyone know if Arko can have legal troubles (like being sued) if it can be proven he "removed authorized users" from RubyCentral AWS account?
brunosutic
·9개월 전·discuss
I use it for learning and play with my kids. I load the program on the board then we wire the components together and get all excited about blinking LEDs or a LCD.

The lack of features (notably Wifi on our boards) and somewhat larger size are benefits for us.