#carbonara_code

1 messages · Page 1 of 1 (latest)

slim meteorBOT
#

đź‘‹ Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1437737649577394188

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

placid pivot
#

đź‘‹ Hi there! Let me take a look

#

If you're not able to just ignore the invoice on your backend, then I believe you could use a Subscription Schedule to update the billing_cycle_anchor

placid pivot
#

From what the documentation says there, I believe it should

potent ether
#

I'll give it a try, thanks a lot for your help

placid pivot
#

I checked on that, and it still generates a $0 invoice

slim meteorBOT
gloomy berry
#

Yeah this isn't really possible. You're effective moving the b_c_a date which always requires a new invoice

potent ether
potent ether
gloomy berry
#

You mean a way to check if you used a trial period?

potent ether
#

Let me explain: we sell dog food through subscriptions, and we send the right amount to cover exactly 28 days. For medical reasons, some dogs need to go through a transition period from kibble to our food. Since the duration of this transition is determined case by case, if someone tells us they still have food left, we need to postpone the subscription payment just that one time. After consulting with other companies in the same field that use Stripe, they suggested adding trial days.
Unfortunately, it’s a situation we only discovered after launching the product, and this system based on subscriptions and trial periods is already in production.

gloomy berry
#

Not easily, no. My recommendation would be to pass metadata in your Subscription update call that sets the trial period which will then be set on the resulting invoice (here). You can use that to ignore the invoice/related events in your code

Just remember to unset it when the trial/extended period ends

potent ether
#

Something like this?

$updatedSubscription = \Stripe\Subscription::update($subscriptionId, [
        'trial_end' => $newTrialEnd,
        'proration_behavior' => 'none',
    ]);

$invoices = \Stripe\Invoice::all([
        'subscription' => $subscriptionId,
        'limit' => 1,
    ]);

\Stripe\Invoice::update($invoiceId, [
            'metadata' => [
                'reason' => 'Trial extension',
                'extended_days' => $additionalDays,
            ],
        ]);
gloomy berry
#

Well it depends on when you app logic that 'breaks your database' is running? Is that triggering on receipt of a webhook event or something?

potent ether
#

Ah well, of course, that way it doesn’t work. We’re using webhooks, so the invoice would arrive directly without the added metadata.

gloomy berry
#

invoice.paid I assume?

potent ether
#

yes

#

exactly

gloomy berry
#

That'll be included in the invoice.paid event

potent ether
#

Ok, so I set the metadata on update, retrieve them from the webhook, and then, of course, delete them.

gloomy berry
#

Should work yes

#

Can unset it on the Subscription via an update with an empty string

potent ether
#

top