#driesvints

1 messages · Page 1 of 1 (latest)

dapper mothBOT
urban saddle
#

One other thing: I saw a strange case the other day where stripe created a new subscription item for the same price on a subscription. Is that a common thing to happen? I always thought stripe would update the subscription item whenever an adjustment came in.

#

Hi, let me help you with this.

jagged yew
#

Maybe create a separate thread for the other question? Not sure why it was moved in here.

urban saddle
#

Please, let's talk in one thread.

#
  1. Why would you need to confirm payments created by Checkout yourself?
#
  1. Could you please share the Subscription ID?
jagged yew
#

Spark sends out an email with a link to a payment page where you can confirm a payment that requires 3D secure. But our customer gets a "You cannot perform this action on PaymentIntents by Checkout" message when they try that. Why can't they perform this action?

urban saddle
#
  1. What's Spark?
jagged yew
#

Could you please share the Subscription ID?
for which question is this? the first or the second? I don't have a subscription ID for the first one since it's not our Stripe account, it's our customer's Stripe account.
for the second question an example would be sub_1Mloic2niB1UWjcExGUY95mv

#

I really think a separate thread for the other issue is better. otherwise we're going to be talking about two things at the same time

#

What's Spark?
Laravel Spark: https://spark.laravel.com

We maintain a large self hosted customer portal solution on top op Laravel.

urban saddle
urban saddle
jagged yew
#
  1. Could you please share the Subscription ID?
    sub_1Mloic2niB1UWjcExGUY95mv
#

I don't know how Spark works and why it sends you emails and tries to manually confirm Checkout Session PaymentIntents. Are you using some sort of plugin?

  1. No it's a custom solution developed in PHP and Vue.

But I only want to know why "You cannot perform this action on PaymentIntents by Checkout" happens on a stripe.confirmCardPayment call when a 3D secure check is needed.

#

Why can't we perform that action?

dapper mothBOT
urban saddle
urban bluff
#

You can't mutate/confirm a PI generated by Checkout outside of Checkout.

jagged yew
#

Well that's the first I heard about it :-/

#

It's also weird that we only got a report now from a customer because this integration has been live for a while now.

#

so, how do people need to perform these checks? Does stripe send emails about these themselves?

urban bluff
#

It's always been this way, so I'm curious to see some examples where this worked!

jagged yew
#

does this also apply for recurring payments from subscriptions which are created from checkout?

urban bluff
jagged yew
#

It's always been this way, so I'm curious to see some examples where this worked!
Well that's what I'm wondering myself. We never gotten reports of it not working.

#

No, just the initial payment
Gotcha

#

Ok, knowing this I'll try to update our integration to not send emails for these type of payments.

Is there an easy way to check if a payment intent was created for a checkout session?

urban bluff
#

The initial on-session confirmation/payment of the subscription (i.e. on the Checkout page) cannot be confirmed outside of that payment page. Subsequent off-session recurring payments we automatically attempt to pay, and failing that can be confirmed manually by your integration without Checkout

urban bluff
#

In any case, you probably want to listen for invoice.payment_action_required/invoice.payment_failed and check the billing_reason field. It'll be subscription_create in scenarios where the user in on-session in Checkout paying, Those are safe to ignore as they'll fire when 3DS/auth is requested for the payment, which Checkout can handle for you (as customer is in-session)

jagged yew
#

Gotcha, thanks @urban bluff I'll try implementing that.

urban bluff
#

Makes sense, I guess the email was sent you your customer who was on-session for an initial subscription confirmation in Checkout

jagged yew
#

What about question nr 2? Does Stripe ever replaces a subscription item with a new one for the same price instead of updating it?

#

Makes sense, I guess the email was sent you your customer who was on-session for an initial subscription confirmation in Checkout
yes that's what happened indeed. But I know now we can ignore that, all good 👍

urban bluff
#

Is that on sub_1Mloic2niB1UWjcExGUY95mv?

#

Where do you see the 'new item'?

jagged yew
#

So we have a constraint in our database on the price_id and the subscription_id. Normally it can never happen that a subscription gets the same price_id twice. So what we got was an event where a subscription suddenly has a new item with the same price id. Stripe removed the old item. But when we tried to insert it in the database the constraint complained.

We have since updated this behavior to check the subscription item id instead so this malfunction won't happen on our side again but I was curious why stripe creates a new subscription item instead of updating the old one.

#

indeed on sub_1Mloic2niB1UWjcExGUY95mv

urban bluff
#

we got was an event where a subscription suddenly has a new item with the same price id
Do you happen to have the evt_xxx ID?