#ben_api

1 messages · Page 1 of 1 (latest)

gloomy belfryBOT
#

👋 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/1318269063205486674

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

umbral prism
strong patrol
#

This doesnt quite look like right to me. So for exaple, we need to be able to allow our users to sell a plan to a customer who should have started lets say 7 days ago. If the plan is a schedule that says phase[0] interval month count 1 iterations 3, phase[1] interval month count 3 iterations 1, end behaviour release.

The subscripiton should sstart 7 days ago and the next invoice should be in 3 weeks because the first phase interval is 1 month.

I can do this with stnadard subs and got that working fine, but i need the same behaviour with our scheduled products which allow user sto build more complex patyment plans

#

So tis is when creating a subscripojnt via a schedule for the first time, not when a sub already exists

umbral prism
#

Can you share an example of a standard subscription where you set this up so I can compare with specifid details

strong patrol
# 

namespace App\Actions\Coach\ConnectSubscription;

use Laravel\Cashier\Cashier;
use App\Enums\ApiExceptionEnum;
use App\Exceptions\HandleException;

// Helpers
use App\Helpers\SubscriptionHelper;

// Models
use App\Models\ConnectAccount;
use App\Models\ConnectCustomer;
use App\Models\ConnectProduct;

/**
 * Creates a subscription in stripe
 *
 * @param ConnectAccount $connect_account
 * @param ConnectCustomer $customer
 * @param ConnectProduct $product
 * @param string $start_at - optional start date for forward or backdating the subscription
 * 
 * @return \Stripe\Subscription - the created subscription with expanded latest invoice
 */

class StripeSubscriptionCreate
{
    public static function handle(ConnectAccount $connect_account, ConnectCustomer $customer, ConnectProduct $product, int $start_at = null): \Stripe\Subscription
    {
        if ($connect_account->stripe_account_id !== $customer->stripe_account_id) {
            throw ApiExceptionEnum::customer_not_authorised->throwable();
        }

        $billing_anchor = SubscriptionHelper::setBillingAnchor($start_at, $product->price);

        try {
            $stripe = Cashier::stripe();
            $stripe_subscription = $stripe->subscriptions->create([
                'customer' => $customer->stripe_customer_id,
                'items' => [
                    [
                        'price' => $product->default_price,
                        'quantity' => 1,
                    ],
                ],
                'backdate_start_date' => $start_at ?? null,
                'billing_cycle_anchor' => $billing_anchor,
                'application_fee_percent' => $connect_account->platform_fee,
                'expand' => ['latest_invoice'],
            ],
            ['stripe_account' => $connect_account->stripe_account_id]);

            return $stripe_subscription;
        } catch (\Exception $e) {
            info($e);
            throw HandleException::handle($e);
        }
    }
}
umbral prism
#

Sorry not that

strong patrol
#

oh

umbral prism
#

My fault, I should have been more explicit

#

Can you share a Subscription ID?

strong patrol
#

I thought we were about marvel over my code

#

yeah il need to set up a new one, 2 secs

#

sub_1QWiJdS8JADFnkdC88uhaH6S

#

This is an example of a stsandard sub where i have achieved the same outcome. The only difference is our shcedule products chain different phases of a plan together, but the requirement is the same

umbral prism
#

Thanks, taking a look at the creation parameters and the behavior of this subscription

#

Okay so I notice the subscription starts in the past with the billing cycle anchor set for one month after the back-dated start date.

strong patrol
#

correct

umbral prism
#

And that generates and Invoice that covers the period from the backdated state date to the billing cylce anchor

strong patrol
#

correct

umbral prism
#

Okay so let's say you do this with a schedule. Are you creating a phase that covers the same periond (back-dated start date to future billing cycle anchor)?

strong patrol
#

Yes, but our products are split in two; those that at standard recurring subs,and those that are staged (schedule with multiple phases).

Both products can start now, in the past, or in the future.

#

The first phase can vary in length to subsequent phases, so it could be a week, it could be 2 momnths, it could be 1 month that iterates 3 times etc

umbral prism
#

How does any of that impact the question I asked?

strong patrol
#

Im giving you the full picutre of how our platform is inteded to work.

Ultimately it shouldnt imapct it, but i am unsure what you are goign to prpopse to wanted to ensure i gave you full context

#

The first phase should be back datable (is that even a word?) and should run as if it started on that past date, irrespective of its iterval, count or iterations

umbral prism
#

Right, I don't think the length or count of iterations should matter at all here and I don't want to confuse the issue.

#

Which schedules, the billing cycle anchor is set per phase

strong patrol
#

but can it be adjusted? as the api docs say it takes an enum only

umbral prism
#

Okay, can I ask you how the future billing cycle anchor you would want to set would line up with the duration of the phases you want to create?

In the Subscription example, the BCA value you provided matches a 1 month billing cycle based on the back-dated start date.

strong patrol
#

It depends on the interval and interval_count of the first phase in the phases array. Lets say it is iterval month and count 2 (2 months), and we are back dating 7 days, the billing cycle anchor should be 2 months from 7 days ago (or 2 months less 7 days in the future)

#

As all subsequent iterations and phases will chain from this

umbral prism
#

Just so I'm clear, in the scenario you described above, the billing cycle would anchor on the end of the first phase? Or would your phases always be out of sync with billing intervals?

strong patrol
#

No, my phases would be in sync but each phase can be billed at different intervals. So if the first phase is inteval month count 2 iterations 3 (will every 2 months for 6 months) the first payment would be taken on creation with a start date of 7 days ago, the second iteration would be on the back dated anchor of 2 months - 7 days from now. everything would continue as normal there after in terms of iteration length and so forth

umbral prism
#

So, in that case, wouldn't you set the billing_cycle_anchor on the 2nd phase to the enum value phase_start?

strong patrol
#

No idea on that part, as i havent gotten that far into the test. The initial. sub created is wrong in terms of its durartion as even though i back dated 7 days, the next bill is 2 months from now rather than 2 months - 7 days

umbral prism
#

Do you have an example Subscription Schedule that demonstrates this problem? Billing is really complex and it helps me to have concrete examples.

strong patrol
#

Yes do you want me to create one that is incorrect? Or you want to see our product structure?

umbral prism
#

I would like to see the incorrect outcome

strong patrol
#

ok hang on

#

sub_1QWiydS8JADFnkdCD6hELW7i

#

this product has phase 0, iterval month count 1 iterations 2, followed by phase 1 interval month count 1 iterations 1, end heaviour rleease.

It hsould have started on the the 9th with the next invoice due on 9th jan 25

#

the next phase start looks correct, but the billing anchor is off

#

It also looks like it has prorated the first invoice too, which is incorrect

umbral prism
#

Right, I do see that on the related first Invoice.

As I understand it, you would expect it to invoice for the full period from 12/9 - 1/9, correct?

strong patrol
#

correct, its actually done 9th dec - 16th dec so approxiamtely 25% increase (which is about right for 7 days).

But the nexrt invoice is due 16th, rather than 9th, which i what needs to change.

umbral prism
#

Would you be able to test some different approaches that I suggest?

strong patrol
#

of course, ive got the skills that pay the bills

umbral prism
#

Okay.

So first approach is to leave the phases as they are currently except include the phases.billing_cycle_anchor: "phase_start" on both.

Second approach: Split the first phase into 2 with the same Price and each with iteraions: 1 but specify billing_cycle_anchor: "phase_start" on the second phase.

strong patrol
#

ok let me try the first one

#

First optoion resulted in the same issue - sub_1QWjIJS8JADFnkdCwd5vw4JS (i will be cancelling this now to try option 2)

#

second il need to work out how i can refactor to do this

gloomy belfryBOT
strong patrol
#

sub_1QWjMDS8JADFnkdCIMwY3dQo - same issue

#

im beginning to tihnk the only way to do this would be to take the first item from our product phases, create a sub and backdate + set billing cycle anchor, then wrap it in a schedule to honour the phase 0 itentions, and add in the subsequnry phases.

I cant see another way to achieve this

noble hinge
#

That is what I've seen other times that I have looked in to similar issues but I am double checking. Unfortunately I do think setting an arbitrary BCA is only possible when creating subscriptions directly, and that its a known limitation that schedules can't do it. Will get back to you with what I can find on whether there is a way to do this

strong patrol
#

Thanks Pompey.

I think you might be right, it looks like Create Subscription based on phase[0] > Create schedule from said subscription > Update schedule to set phase[0] to honour original phase[0] iterations and add all subsequent phases.

So 3 API calls

noble hinge
#

Yep, unfortunately I am not finding a way to backdate the subscription properly like this with a schedule or to reduce the number of calls that need to happen here. I can definitely file feature requests for both of those, but for now all three requests are needed here

strong patrol
#

This will be fun to write. I have to do something similar for future dating too but il get to that separately. I guess its time for me to go away, gently wipe away my tears, and get to work

#

Thanks for the support from both of you!

noble hinge
#

Of course, just let us know if you run in to anything else. Hopefully there will be less tears on the future dating question, let us know if we can look in to anything for that