Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Topher/more sales tax updates #9

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

topherfangio
Copy link

Add some additional code necessary for the sales tax updates. Basically another place to call the subscription_options method.

# Go ahead and create the subscription
Stripe::Subscription.create(sub_opts)

# Now save the customer's plan
customer.plan = plan.stripe_id
customer.save

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were these two lines responsible for creating the subscription w/in Stripe? I tried to find any mention of this in the Stripe API docs and did not see anything about how a subscription gets created by setting a plan id on the customer.

Can these be removed now? does making a stripe subscription and passing in the customer and item[{plan:}] like you did properly associate the stripe sub and customer objects?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So based on my memory and some digging, yes, the old version of the API allowed us to send a plan_id with the customer on creation and it would create the subscription to that plan.

Based on some of the Changelog docs I'm reading, that appears to be the case (https://stripe.com/docs/upgrades#2015-10-16):

Returns an error if a tax_percent is provided without a plan during a customer update or creation.

I take this to mean that at one point, you could pass along both the plan and tax percent when creating a customer and Stripe would take that and create the necessary objects. I think we can test it if need be.

To answer your question about removal: removing that made some specs fail; I tried that first (I believe the specs were expecting the plan to have been set).

I'm happy to dig into this some more; I definitely don't want to push out code that will cause issues! My hope was to get this on staging and do some testing to make sure we don't get duplicate charges or something weird like that. I also need to test the order bumps; I can't seem to get those to work locally.

Copy link

@seattlecyclist seattlecyclist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds good.

I would still like to see PR #8 get used in mothership for a day or so before the new commit ref for this PR gets used too.

But thats a mothership issue and not a /koudoku issue.

Lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants