#sergixel04

1 messages · Page 1 of 1 (latest)

nova nightBOT
#

Hello sergixel04, we'll be with you shortly! 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.
• sergixel04, 3 days ago, 37 messages
• sergixel04, 3 days ago, 78 messages
• sergixel04, 6 days ago, 62 messages

pale prawn
#

👋 happy to help

#

we were discussing this on Friday, where are you stuck now?

pure tide
#

Yes! Hello @pale prawn

Right now it's working fine, but I have a doubt.

I send the critical fragments of the code to help understand

This one for creating business (incrementing the subscription quantity). Working fine

public function createBusiness()
{
$stripeSubscription = \Stripe\Subscription::retrieve($subscription->stripe_id);
        $items = [
            [
                'id' => $stripeSubscription->items->data[0]->id,
                'quantity' => $quantity + 1
            ],
        ];

$updatedSubscription = \Stripe\Subscription::update($stripeSubscription['id'], [
                'items' => $items,
                'proration_behavior' => 'always_invoice',
            ]);
}

This method for deactivating one account, that means that the subscription quantity will be -1. And handle external logic with my ddbb

public function deactivateBusiness(Request $request)
    {
        $business = User::where('token', $request->token)->first();
        if ($business) {
            Stripe::setApiKey(config('app.stripe_secret'));
            $user = User::find(auth()->id());
            $subscription = $user->subscription('main');
            $quantity = $subscription->quantity;

            $stripeSubscription = \Stripe\Subscription::retrieve($subscription->stripe_id);
            $items = [
                [
                    'id' => $stripeSubscription->items->data[0]->id,
                    'quantity' => $quantity - 1
                ],
            ];

            \Stripe\Subscription::update($stripeSubscription['id'], [
                'items' => $items,
                'proration_behavior' => 'none',
            ]);

            $business->is_deactivated = true;
            $business->save();

            // return
            ]);
        }
    }
#

And this one is for activating an business account that was deactivated.

public function activateBusiness(Request $request)
    {
        $business = User::where('token', $request->token)->first();
        if ($business) {
            Stripe::setApiKey(config('app.stripe_secret'));
            $user = User::find(auth()->id());
            $subscription = $user->subscription('main');
            $quantity = $subscription->quantity;

            $stripeSubscription = \Stripe\Subscription::retrieve($subscription->stripe_id);
            $items = [
                [
                    'id' => $stripeSubscription->items->data[0]->id,
                    'quantity' => $quantity + 1
                ],
            ];

            \Stripe\Subscription::update($stripeSubscription['id'], [
                'items' => $items,
                'proration_behavior' => 'none',
            ]);

            $business->is_deactivated = false;
            $business->save();

            // return
            ]);
        }
    }
#

When user deactivates and activates a business, I don't charge prorations 'prorations_behavior' => 'none' because I've already charged them.

But I have this doubt.

What would happen if the subscription is monthly.

A user subscribes, then the same day add a business account and pay prorations, which is correct and working.

But 22th November the user deactivates the business account and 24th November activates the account, and do the same for 22th December and 24th December.

In this case, the user is avoiding to pay for the usage of that account?

pale prawn
#

did you test it out using test clocks?

pure tide
#

Nope, I will test that. In case the user is avoiding paying what would be the solution?

#

Because if I comment proration_behaviour I've already tested and it's changing the next payment subscription to different prices, affecting also to add other business account, so that's not working

#

And I think if proration_behaviour is set to always_invoice in that case, for the UX would not be the best option

pale prawn
#

it really depends on how you're provisioning the access to your service

pure tide
#

I think the correct way would be that if you deactivate 1 account. Then, after the next subscription's payment if you activate the business account, then you will have to pay prorations for it

pale prawn
#

I really don't think that proration_behavior; none is what you should be using

pure tide
#

If I use always_invoice, I see some problems:

For example, a user can accidentally deactivate one business account, then if he press on activate again. Then it will charge the prorations again, right?

#

so I don't know how to handle this

pale prawn
#

the prorartion would be 0 in that case

#

@pure tide you need to use test clocks and test your integration

#

and try all the possible scenarios

pure tide
#

thank you @pale prawn will use test clock and do more testing.

I am thinking also if set proration_behaviour when deactivated on none, and when activate bussiness on none makes sense

pale prawn