Roadmap / Planning for Stripe Upgrades

[mcrumm]

First, thanks to everyone maintaining this library! I'm curious about the roadmap, and whether or not there's currently a plan for continued parity with the Stripe API.

Today's release of v0.30.0 of stripe-mock resulted in a broken CI build (stripe/stripe-mock#110), related specifically (in our case) to the new query parameter validation (stripe/stripe-mock@09826da).

Attempting to fix that condition in stripity_stripe landed me here, wondering how to handle the upgrade to 2018-08-23...

[snewcomer]

@mcrumm 👋🏿 Appreciate the issue. We are currently integrating updates to the stripe API as ppl need new features. I think we are at a good point to update to the latest stripe version and stripe mock. I’m not too sure the surface area is large. I have time next week but if you had time I can help with a PR.

Looks like two things - some updates to API parameters to match the August version and then updating to work with the latest stripe mock. So two separate PRs I think would be good with maybe the first being updating to work with the latest stripe mock (we are on 0.16.1 fyi). What do you think?

[mcrumm]

Hey @snewcomer! I'd be happy to dive into the stripe-mock update. The biggest things I saw were related to query params (I'm pretty sure I already have this sorted), and some strangeness around the deletable resources, as the converter seemed to be returning the full (albeit empty, save for the ID) struct, instead of a map with a deleted key.

Where the latest stripe-mock starts to introduce test errors due to API changes (for instance, with at_period_end on subscription delete), how should I proceed? Let the tests fail, and circle back around in another PR?

[snewcomer]

Yep good find @mcrumm! The deleted issue was an issue I saw when I updated to 0.23.0 (could be an earlier version as well).

So essentially we need to replace delete/2 test like this:

assert {:ok, %{deleted: deleted, id: _id}}

with something like

 assert {:ok, %Stripe.SubscriptionItem{}}

as shown now in the docs in the Returns section

[mcrumm]

@snewcomer How do we want to handle BC breaks within the latest Stripe API upgrades? Should we be looking at a 3.0 release?

Here are the changelog entries for the last two upgrades:

2018-08-23

• You can no longer set at_period_end in the subscription DELETE endpoints. The DELETE endpoint is reserved for immediate canceling going forward. Use cancel_at_period_end on the subscription update endpoints instead.
• The business_vat_id field was changed from String to Hash called tax_info, consisting of tax_id and type, in both requests and responses.
• The amount field field in the tiers configuration for plans was renamed to unit_amount.

2018-07-27

• The subscription endpoints no longer support the source parameter. If you want to change the default source for a customer, instead use the source creation API to add the new source and then the customer update API to set it as the default.
• When ending a trial on a subscription using trial_end=now the updated subscription will now receive a trial_end timestamp from the time of the request rather than being unset.
• The percent_off field of coupons was changed from Integer to Float, with a precision of two decimal places.
• When creating or updating a customer the email parameter must contain an email address of valid shape.

[snewcomer]

@mcrumm Generally I believe we have been handling these as minor releases and detailing those in the release notes.

[mcrumm]

So to get to 2018-08-23, we need the following updates:

• Change coupon.percent_off type from pos_integer to float (guard for negative floats?)
• Remove source from Stripe.Subscription.create/2
• Replace customer.business_vat_id (string) with customer.tax_info (map)
• Remove (deprecate?) Stripe.Subscription.delete/3

Additionally, we discussed refactoring Stripe.API.request/5 to get back down to a single function body.

Anything else?

[snewcomer]

Seems right! Lmk if you want any help or not! Otherwise, I'll be here for review 👍