#Isaac - Invoices
1 messages ยท Page 1 of 1 (latest)
Sure thing! The one in which the tax is not updated to match the new incoming tax rate?
Yup, that one
Here's a request ID for a call in which the tax is not overridden: req_Rvk9SWrgDd4gbl
For good measure, here's a request ID in which the subscription does not have a default tax rate set and passing in the subscription_default_tax_rates works as expected: req_VIZXg65TqR8hY7
Okay so you're not seeing the really high tax rate being applied in your upcoming invoice request?
We don't store payloads on GET requests so I can't see it
Ahโ haha yeah that's Chicago for you, and no it is not coming back. The customer's originally applied tax rate is in a state without sales tax, and so it should go from tax 0 to tax $29.
The TaxRate record that is associated with that initial API request has this: percentage โ 102500
Which is what I though seemed high
Yeah, that's actually correct. It should be about 10.25% in the end
Which I do see as correct in the dashboard
Is there anything I can provide from the response payload to help clarify?
I'm trying to reproduce the requests on my end
Sweet, I really appreciate the help. Been pulling my hair out for the last hour and a half on this one!
@gentle gull Here's what I tried
1/ Create a subscription with a tax rate of 10%
2/ Look at upcoming invoice, see 10% tax rate
2/ Look at upcoming invoice with a different tax rate for 20% and see the 20% tax rate calculated
right now it seems to work as expected for me
oh wait
Interesting. This is with default_tax_rates on the new subscription set?
are you mixing things up?
Possibly!
you set default_tax_rates on the subscription item
and then you try to override it globally on the subscription which wouldn't work
Huh. We're creating these using subscription schedules which might've lead to the confusion. Am I able to override tax on a subscriptions line item?
Ah shoot I see it nowโ default_tax_rates is a key on the phase object.
For the subscription schedule.
Thank you so much @lavish oriole , @lusty talon โ I think this gets me moving!
Yay!
I might have misread your logs sorry
yeah okay my assumption was wrong
Still, schedules should have nothing to do with it and it works totally fine for me
Interesting.
I mean I'm sure there's confusion somewhere. Can you share exact end to end code?
Happy to. One moment.
Previewing upcoming invoice:
const options = {};
if (coupon) options.coupon = coupon.id;
if (taxRate) options.subscription_default_tax_rates = [taxRate];
if (subscription) options.subscription = subscriptionID;
if (price) options.subscription_items = [{ price }];
try {
const invoice = await stripeClient.invoices.retrieveUpcoming({
customer: stripeCustomer.id,
...options
});
const preview = mapDictionary(FROM_STRIPE_INVOICE_DICT, invoice);
return {
...preview,
isTrialEligible
};
} catch (err) {
if (err.statusCode === 404) throw new NotFoundError('Preview invoice could not found');
throw err;
}
If it helps, subscription creation:
if (isTrialEligible) options.trial = true;
if (isTrialEligible) options.end_date = getUnixTime(addDays(new Date(), 7));
if (paymentMethod) options.default_payment_method = paymentMethod;
if (taxRate) options.default_tax_rates = [taxRate];
const schedule = await stripeClient.subscriptionSchedules.create({
customer: stripeCustomer.id,
expand: ['subscription', 'subscription.latest_invoice', 'subscription.latest_invoice.discounts'],
start_date: 'now',
default_settings: {
default_payment_method: options.default_payment_method
},
phases: [{
items: [{
price
}],
...options
}]
});
return mapDictionary(FROM_STRIPE_SUBSCRIPTION_DICT, { ...schedule.subscription, schedule });
ack thanks, I'm really confused by half your code ๐
Haha yeah it's the result of several developers touching the same files. I can clean this up / simplify if that's helpful, but this is exactly as we do it!
okay can you just give me the raw JSON output of the invoice upcoming?
I want to see it for myself
thanks looking
Made with this cURL, for reference, which is a replica of what the API would do:
curl -v https://api.stripe.com/v1/invoices/upcoming\?customer\=cus_LkF3Tvfj8xo2zh\&subscription\=sub_1L2kaSHHHT1qJ1rwzqT38utV\&subscription_default_tax_rates\[\]\=txr_1KvpZ1HHHT1qJ1rweqh8uKK4 \
-u sk_test_...
A few minutes ago.
are you sure? I don't see any request for this
I'll do it again if that helps, sure.
ah wait it's from like 50 minutes ago
that's why
I was looking at the past 3 minutes of logs since you have so many
Haha yeah we have a lot of testing going on.
I ran the request again.
Via cURL, anyhow.
perfect cna I get the JSON?
Sure, it's the same as before though.
just to be super sure ๐
Tada!
okay clearly it doesn't care about your tax rate in your call and it works for mine
Ignore the address change on the customer, 1828 is the actual street number made in both requests, I changed it 123 for sanitization in the first JSON file (though it doesn't reveal anything as the rest of the address is fake)
either it's a weird schedule thing, or it's the tax rate being 0 which I haven't tried
give me a few minutes
I suspect it's the schedule, though I haven't tested that.
Would be pretty funny if the 0% tax rate to 10.25% rate was somehow an issue, though.
I mean there's clearly a bug, not sure which one I want to figure out is true ๐
Okay I tried with a schedule, still works. Tried with a 0% tax rate, still works totally fine too. What the heck
oh wait you are doing a ton of stuff to that poor schedule
for example it has more future phases too
Okay I think this is more an issue that the subscription is managed by a schedule and your next phase is resetting the default tax rate so we're taking that into account
Yeah I'm sorry I don't have anything obvious right now and your schedule has been updated many times and I'm totally losing myself trying to make sense of this ๐ฆ
Really sorry but we both need to run too. @gentle gull can you write in via https://support.stripe.com/contact/email and mention my name (koopajah)? I'll find it and try to have someone on my team chase this down for you