#varovas

1 messages · Page 1 of 1 (latest)

distant quartzBOT
teal coral
#

You could check laravel spark they have a billing per seat function

lavish elbow
#

They are using prorations for upgrade/downgrade as I know

#

So if the customer downgrades, he will get credit for next invoice, we do not want that 🙂

unkempt vigil
teal coral
#

If you use cashier then ->noProrate() would be the function

lavish elbow
#

Yes, but then if user on the same billing cycle will upgrade, he will pay again. Example, has 2 users. Downgrades to 1. No proration. Then upgrades again to 2 users, pays extra for 1 user, despite he already paid for 2 in this billing cycle

unkempt vigil
#

They will pay the difference between the two prices but not the same price twice

lavish elbow
#

We tested this solution. 1. Customer creates subscription with 2 users and pays 10 Euros for each. Then on the same day downgrade to 1 user. On the downgrade we set noProrate(). And then the same day user upgraded again to 2 users with proration_behavior=always_invoice and was charged 10 euro, despite that he already paid for 2 users.

#

This is what test clock gives in this scenario

unkempt vigil
#

Can you share the SubscriptionId ?

lavish elbow
#

sub_1MlAqLH8sY2z9xZsflMcTO3g

unkempt vigil
#

Thanks for sharing let me check

distant quartzBOT
random harbor
#

Thanks for your patience, unfortunately I don't think we have a way to configure proration to work the way that you want here. Credit would usually be the thing that prevents the user from re-paying for seats. So I think the way to achieve this would be custom logic on your side

#

The two immediate ways I can think to do that would be:

  1. Store the max qty of seats that the user has paid for and switch the quantity to that without proration before upgrading to a higher quantity than that.
  2. If the users will only have one subscription, you can give out credit and just reset it every month. This would probably make invoices more confusing but it feels like it may still be worth mentioning.
lavish elbow
#

Another idea came up to my mind that if there is a way to switch subscription prices just before next billing cycle? In this way we could have max users on our side. And then just before billing we could update subscription. I mean update subscription immediately in stripe only when customer upgrades, and downgrade only before billing cycle if needed

random harbor
lavish elbow
#

Ok, I will take a look on that. And the another issue (if that's the issue), we are storing payment methods identically as shown in laravel cashier docs. But when we use test card that has 3d secure, every time user update subscription, he has to authenticate with 3d secure. Is this a normal behaviour, or we are doing something wrong.

image.png
random harbor
#

That would definitely be the correct behavior for that bottom card

#

For the top one this is likely expected because you are presumably not designating this as an off-session change.

#

Like basically after you set it up, it won't ask for 3DS again as long as you pass the flag to designate that the user isn't arround

lavish elbow
#

Do I have on upgrade and subscription create set off_session=true?

#

$subscription = $user->newSubscription($plan['plan_slug'], $stripePrices) ->create($attributes['payment_method'], [ 'off_session' => true ]);

#

We set it to true, but user still has to authenticate (top card)

random harbor
#

Interesting. That should be what is needed to have that card not ask for 3DS auth again. Can you send the request ID of a time you made this change and got 3DS? (req_123)

lavish elbow
#

Wait a minute, I will make a fresh subscription

#

This is request to attach payment method: req_hwX0uFaFiAFG5L
This is subscription create: req_j9Zyzx3fk61A7l
This is confirmation: req_Mgo0fTkKlf1LP0

random harbor
#

Thank you, checking in to those requests

#

It is a per-request setting. So it needs to be set each time you make a request on the subscription (if it will result in a payment) or on the payment intent itself

lavish elbow
#

This is a little bit confusing. which request should include off_session ?

random harbor
lavish elbow
#

This request is after the customer tried to create subscription. This happens when subscription throws IncompletePayment exception. If I understand correctly, when user saves payment method. And then tries to use it, he shouldnt be asked for authentication?

random harbor
#

In test mode, with that specific test card, the rule is that it can be used without invoking 3DS again but only if the API calls related to the payment are designated as off session.

#

Unfortunately it looks like we don't have a 3DS test card that allows on session payments without 3DS

lavish elbow
#

I think we do not include off_session attribute to card confirmation and that is the problem. I will check this. Ok, thank you for your time. I will take a look to subscription schedules and see if I can achieve what I want 🙂

random harbor
#

Yes, once you include that the 3DS should go away in test mode. In live mode obviously just pass the one that is correct for whether your user is actually on session or not. Glad that could help, good luck implementing the schedules solution!

lavish elbow
#

I checked 3DS and it seems that setup inter conform has the usage: off_session for a card

random harbor
#

Not sure how clear this is already, but on session payments refer to when the customer is present and doing something on your webpage/app. So them filling out their card details in your form would be a classic on session setup. Off session is for when some automatic charge happens when the customer is not around. So like the subscription cycling or changing automatically

lavish elbow
#

Hmm. Basically what I am doing. Customer comes to his account on our web app. Then he adds payment method to his account. Enters card number, cvc, post code, expire date. Then confirms that card with 3DS and that card then is stored to stripe as customer payment method. Then, customer goes to next page and can select Plans: free, minimum, medium, maximum. After that he select how much users does he want with that plan and then subscribes. And I thought if customer previously confirmed 3DS when saved payment method, he will not be asked to authenticate 3DS when creating a subscription

random harbor
#

In live mode that is ultimately up to the bank. They often choose not to request 3DS again if it has just been performed but there is always the chance that they might

#

That is actually why we recommend avoiding using a setup intent if you intend to charge the card immediately. So if they are making a payment on the subscription immediately, it might be better to just wait until the subscription is created and use the payment intent on the first invoice of the subscription. Otherwise there will always be a chance that 3DS is requested twice

lavish elbow
#

I understand that. But I remembered another scenario. For example, user create or upgrade subscription, he is requested to confirm 3DS. And the if user accidentally denies confirmation, or changed his mind for example and wants to stick with his current subscription, he cannot revert back. Because subscription in stripe was changed before he has to to confirm 3DS. How to handle that?

quick verge
#

If the payment fails then we don't apply the update to the subscription

lavish elbow
#

I read that, but I think pending updates is not very well implemented in laravel cashier package. Because this is how laravle cashier handle pending updates:
if ($payload['payment_behavior'] !== StripeSubscription::PAYMENT_BEHAVIOR_PENDING_IF_INCOMPLETE) { $payload['cancel_at_period_end'] = false; }

#

But cancel_at_period_end is not allowed

quick verge
#

Ah hmm, our team unfortunately doesnt' know about laravel cashier package. We mostly work with native APIs related questions 😦

#

To be clear, Pending updates is exactly how you'd handle this. I'd recommend talking to our support team to see if they can provide any alternatives here (they should be able to take a look and raise it internally to the right team)
https://support.stripe.com/?contact=true