#sergixel04

1 messages · Page 1 of 1 (latest)

next lionBOT
heady quiver
#

Hi there, I can only support if you have a direct integration with Stripe. If you have questions related to a 3rd-party plugin, I'd suggest you to reach out to the plugin developer directly.

lime meadow
#

I can use Stripe SDK. Would be this correct?

public function handleSubscriptionAccounts(Request $request)
{
$user = User::find(auth()->id());

    $subscription = $user->subscription('main');
    $subscription->incrementQuantity($request->accountsNumber);

    $invoice = $subscription->asStripeSubscription()->previewUpcomingInvoice([
        'subscription_items' => [
            [
                'id' => $subscription->asStripeSubscription()->items->data[0]->id,
                'quantity' => $subscription->quantity,
            ],
        ],
    ]);
    $amount_due = $invoice->total; 

    Stripe::setApiKey(config('cashier.secret'));

    $session = Session::create([
        'payment_method_types' => ['card'],
        'line_items' => [[
            'name' => 'Prorrateo',
            'amount' => $amount_due,
            'currency' => 'usd',
            'quantity' => 1,
        ]],
        'customer' => $user->stripe_id,
        'success_url' => route('checkout.success'),
        'cancel_url' => route('checkout.cancel'),
    ]);

    return redirect($session->url);
}
heady quiver
#

You are creating a new subscription here, not updating an existing one

#

Also the subscription can use the default_payment_method to pay the invoice, there's no need to ask the customer to explicitly pay again.

lime meadow
#

So the user when choose the account's number they want and click on the button that submit the event.

It will autocharge them?

heady quiver
#

"So the user when choose the account's number they want and click on the button that submit the event." -> not sure what this means

lime meadow
#

Have this for testing, a user can select the number of extra accounts he wants to add to his current subscription. My pricing model is Tiered pricing and Graduated.

When the user submit the form, it will update the user's subscription quantity. But how and when the user will pay this amount?

#

When Stripe detects that that user's subscription has been updated, it will automatically charge the proration?

next lionBOT
civic steeple
#

We'll generate a new invoice for a payment to reflect the changes, and attempt automatic payment assuming there's a PM saved on the subscription/customer

lime meadow
#

what does PM mean? Sorry I'm not english native

#

Is there someway to retrieve the proration cost to this view? In order that customer understands that when he clicks he will pay for X€ amount

#

to get a button that says Pay X€

civic steeple
civic steeple
lime meadow
#

Alright, but the problem I see if I understand, is that the value of the upcoming invoice would be correct after user submit the form

civic steeple
#

I don't understand the question

lime meadow
#

This is the way the SaaS should work I think:

A user is subscribed to a plan. He wants more accounts, choose the number he want and submit the form. Updating the subscription's quantity.

But this subscription is monthly, so when the user adds an account it will create a proration.

So I would like to automatically charge that proration to the user. But also give that information to him, allowing that when he clicks on the button he understand that he will pay the proration cost

#

and that he will pay X€

civic steeple
#

Yep, that's what the upcoming invoice endpoint helps with. You pass it the parameters that match the update you're about to do and we'll return a invoice preview

#

So in this scenario you'd pass both subscription and the subscription_items parameter, where the items matches the updated items (i.e. new quantity)

lime meadow
#

Perfect I get here the data of upcoming invoice, This data is useful, but I see some problems.

24194/100 is the amount that the customer will pay next month for the subscription, but not the proration amount.

#

Another problem I think is that the prorations are not being automatically charged right? I don't understand what's happening. Wait, I send you a screenshot

civic steeple
#

Hard for me to know what is unexpected without seeing the request/parameters you sent

lime meadow
#
public function handleSubscriptionAccounts(Request $request)
    {
        $user = User::find(auth()->id());

        $subscription = $user->subscription('main');
        // $subscription->incrementQuantity($request->accountsNumber);

        Stripe::setApiKey(config('app.stripe_secret'));
        $proration_date = time();
        $subscription = \Stripe\Subscription::retrieve($subscription->stripe_id);

        $items = [
            [
                'id' => $subscription->items->data[0]->id,
            ],
        ];

        $invoice = \Stripe\Invoice::upcoming([
            'customer' => $user->stripe_id,
            'subscription' => $subscription->stripe_id,
            'subscription_items' => $items,
            'subscription_proration_date' => $proration_date,
        ]);

        return dd($invoice);
    }
civic steeple
#

Can you share the req_xxx ID? There's a lot of variables in there without any context

lime meadow
#

Yes! Can i put it here?

#

or I have to send it to your DM?

civic steeple
#

Here is fine

lime meadow
#

I think is this one req_gzOK1lgwWSaSkT

civic steeple
#

Can can you help me understand what is unexpected/confusing in the response?

#

(fi you can pase the full JSON response too, that'd be good – we don't log those)

lime meadow
#

I will try to use Postman, i get data and render it with Laravel dd()

The problem I see is that the prorations are not being charged right?

civic steeple
#

Difficult for me to know for sure as the line items are non-English, but they look like prorations (i.e. time remaining on...)

lime meadow
#

I send you the screenshot in english sorry

civic steeple
#

Yup, all of those line items are prorations. Why do you think they're not being charged?

#

I see a net of around $90 of prorations

next lionBOT
lime meadow
#

where can I check that those 90€ has been charged?=

#

I think they're not being charged because in Payments it only shows one payment of the user that has suscribed

civic steeple
#

Well, what do you mean b y 'charged'? It's right there on the invoice. The sum of all the items

#

To be clear this is the response from the upcoming invoice endpoint, yes?

lime meadow
#

Nope, that prorations are real in Testing mode but in that case, the subscription has been updated, generating that prorations, but I don't understand why is not charging it

#

I have understood the endpoint function, working right now, thanks so much! But do you know why prorations when they are made, they are not being charged?

tender lotus
#

because the default behaviour is that when you update a subscription, proration adjustments(those line items in your screenshots) are created, and those are "pulled into" the next recurring invoice and charged in that.

lime meadow
#

There is some option to automatically charge prorations?

For example, if the subscription life cycle is yearly, we would have to wait until next year to charge that amount? What whould happen if user cancels subscription before next recurring invoice?

tender lotus
#

proration_behavior:"always_invoice"

lime meadow
#

don't understand sorry

#

proration_behavior:"always_invoice" I should put this updating the subscription?

#

Using \Stripe\Subscription::update

Is it mandatory to specify items?

or this is fine?

\Stripe\Subscription::update('$subscription['id']', [
'proration_behavior' => 'always_invoice',
]);

tender lotus
#

it's mandatory to specify items

#

proration_behavior is not a field or setting on the Subscription object, it's an argument you pass as part of making an update

lime meadow
#

To understand, this should be the way to handle it?

public function handleSubscriptionAccounts(Request $request)
    {
        Stripe::setApiKey(config('app.stripe_secret'));

        $user = User::find(auth()->id());
        $subscription = $user->subscription('main');
        // $subscription->incrementQuantity($request->accountsNumber);

        
        $proration_date = time();
        $subscription = \Stripe\Subscription::retrieve($subscription->stripe_id);
        $items = [
            [
                'id' => $subscription->items->data[0]->id,
                'quantity' => $request->accountsNumber
            ],
        ];
        \Stripe\Subscription::update($subscription->stripe_id, [
            'items' => $items,
            'proration_behavior' => 'always_invoice',
          ]);

        $invoice = \Stripe\Invoice::upcoming([
            'customer' => $user->stripe_id,
            'subscription' => $subscription['id'],
            'subscription_items' => $items,
            'subscription_proration_date' => $proration_date,
        ]);

        $totalAmount = $invoice['amount_due'] / 100;
        $invoiceLines = $invoice['lines']['data'];

        $prorations = [];
        foreach ($invoiceLines as $invoiceLine) {
            $prorations[] += $invoiceLine['amount'] / 100;
        }
        $totalProrations = array_sum($prorations);

        return dd($totalAmount, $totalProrations);
    }
#

the update subscription

tender lotus
#

well in that code you are changing the subscription and charging the customer immediately, and after that you're looking at their upcoming invoice(which now won't have any proration since you already charged for it).

#

but the update subscription part perhaps does what I think you asked for — it wil calculate the prorated amounts for the new plan minus the prorated amount on the old plan, and it will issue an invoice for it immediately.
https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment:~:text=To bill a customer immediately for a change to a subscription on the same billing cycle%2C set proration_behavior to always_invoice. This calculates the proration%2C then immediately generates an invoice after making the switch.

#

ultimately, run things in test mode and see what they do!

lime meadow
#

Perfect, thank you I undersntad. The prorations has to be calculated before the subscription is updated to preview it.

About charging the customer inmediately. It will only charge the prorations right?

For example if the user subscribed at 17th Oct (pay for 20€ + VAT at Checkout).

And then at 28th Oct add 2 extra accounts (in this moment he will pay only the prorations?)

And then at 17h Nov he will pay the total amount of those 3 accounts, right?