#luxterful_docs

1 messages · Page 1 of 1 (latest)

solid hedgeBOT
#

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

📝 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.

fluid sable
#

It'll remain in an incomplete status for ~23 hours before we'd expire/cancel it. Generally you'd just retry the payment and it'll transition normally

How subscriptions work

Manage recurring payments and subscription lifecycles.

mortal thorn
#

since stripe charges the user down to the second, does the period of the subscription only start as soon as it is active?

fluid sable
#

No, the period starts according to the creation time of the sub

mortal thorn
#

Generally you'd just retry the payment and it'll transition normally

I guess therefore i need to store something in the session so that the user can still confirm it after the redirect after the failed approach. What do i store?

fluid sable
#

You'd need the pi_abc_secret_xyz as that's what is passed to the confirmPayment function

#

It's on the latest_invoice[payment_intent] field when you create the Subscription. You'd need to 'expand' those fields

mortal thorn
#

gotcha. but i am confused now. On the docs of the PaymentIntent object it sais:

It should not be stored, logged, or exposed to anyone other than the customer.

But for this to work i need to store it in the session, right?

fluid sable
#

The advice generally means not to allow other customers to access the secret (as it pertains to a payment irrelevant to them). They have to be available on the front-end

mortal thorn
#

ahaaa so it is not meant to read those 3 conditions separately?
i read

  1. do not store it
  2. do not log it
  3. do not expose it to others

I think you should update those docs to make this more clear. WDYT?

fluid sable
#

Yeah, maybe

#

But we return the secret in URL params in the return_url so it's definitely safe to 'expose' on the frontend

mortal thorn
#

ahaa!! good to know

fluid sable
#

Nobody can do anything with it, without your secret key, other than confirm the payment

mortal thorn
#

gotcha. But since the subscription period starts on subscription creation what happens to a "long running session user"

What i mean is if a user goes to the checkout. tries to purchase, but it fails. We store the client_secret

the user comes back in 2 days and confirms it successfully. the user wont have 2 days less of the period

fluid sable
#

Yeah, technically. I guess if that's important to you then you'd just immediately cancel the subscription and start over

fluid sable
#

So the 'grace period' is short and if they'd return after 23 hours you'd need to create a new Subscription

mortal thorn
#

ahaaaaa, makes sense!
but immagine a lot of users do it that way. Does this mean our stripe dashboard gets jamed with lots of canceld subs?

fluid sable
#

Yeah I guess, unfortunate consequence. But maybe you're optimising for a problem that doesn't yet exist 🙂

mortal thorn
#

we already run our business since some years and we know such things happen often xD

#

i think running a cron job and deleting subscriptions that are canceled that way makes sense to keep things clean, right?

fluid sable
#

Well in the case of a Subscription deletion/cancellation is the same thing

#

You can't delete them unfortunately

mortal thorn
#

haha thats a pitty but ok

#

since we have a ecommerce page selling subscriptions we have 95% users which are basically "guests" and dont exist in our DB yet. We need to create the user as soon as the payment went through.

We listen for the webhook "customer.subscription created" to activate the user account in the DB but therefore it needs to exist.

I am wondering at what point of time we need to create the user in the DB?

fluid sable
#

I guess that's an implemenation detail of your app? Like it probably only makes sense to create a 'user' in your system if they actually pay, right?

#

In which case listen for invoice.paid events instead

mortal thorn
#

yea you got it.
okay, interesting

#

ok but we create our user during the payment process and not in the webhook because the user needs to set a password right after the payment.

#

how would this work then?

fluid sable
#

Hmm, trickier and generally not somethng we'd recommend as there' no guarantee your customer stays on-session. But you'd just wait until confirmPayment resolves and check the status and proceed from there

mortal thorn
#

Do you think it makes sense to switch to paymentintents / setupintents instead of using the subscription API?

with this we can wait with the customer creation after the redirect and create the DB user and subscription there in sequence

#

So i would use this: https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=payment
and this: https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=setup

... docs to implement it

Collect payment details before creating an Intent

Build an integration where you can render the Payment Element prior to creating a PaymentIntent or SetupIntent.

Collect payment details before creating an Intent

Build an integration where you can render the Payment Element prior to creating a PaymentIntent or SetupIntent.

#

WDYT?

fluid sable
#

Do you think it makes sense to switch to paymentintents / setupintents instead of using the subscription API?
Not unless you want to handle the recurring part yourself, no

mortal thorn
#

what do you mean with "recurring"?

solid hedgeBOT
fluid sable
#

Well you're creating a Subscription right. You want the payment to happen every mnth/year automatically

#

If you use Payment Intents directly then you lose that

mortal thorn
#

I thought the payment method used to pay for the payment intent is stored inside the subscription and used on the next period?

fluid sable
#

You asked me this:

Do you think it makes sense to switch to paymentintents / setupintents instead of using the subscription API?
To which the answer is no. If you don't use the Subscriptions API we don't handle the recurring payments

#

You'd need to manually create an intent every month/year

mortal thorn
#

sorry for the confusion

fluid sable
#

I think you're overthinking this problem really

#

My recommendation would be to create your user before the Stripe Customer/Subscription, and then have them set a password post-payment

#

If they don't complete the payment then you still have a user record you can use if/when they return

sacred depot
#

hi! I'm taking over this thread. let me know if you have other questions!

mortal thorn
#

we have several issues right now with our process and i would like to restructure it to solve those issue.

Right now we use setup intents. they are beeing created as soon as the user opens the checkout page. on the checkout page we also have the plan selection and stripe elements for the payment

We offer a 12 month plan with a 7 day trial
and a 3 month plan WITHOUT trial

Because we use setup intents the users which choose the 3 month plan and use google pay see 0.00€ on the google pay popup.

Additionally we have a user which abuses us to iterate credit cards. We already raised a ticket with stripe and are in discussions there.
Because the setup intent is beeing created as soon as the page loads adding a captcha does not work since there is no time for the captcha to see if it is a real user.

Thats why we want to create everything post payment.

there are 3 modes for stripe elements "setup", "payment" and "subscription" and i am still wondering which would be the best for our case?

sacred depot
#

there are 3 modes for stripe elements "setup", "payment" and "subscription" and i am still wondering which would be the best for our case?
if you create a SetupIntent, then is has to be setup

#

but like mentioned earlier, it would make more sense to directly create a Subscription object instead of a SetupIntent.

mortal thorn
#

is it possible to switch between the modes via elements.update?

#

sorry for asking so many detailed questions but i really would like to become an expert in stripe

sacred depot
mortal thorn
#

and i could use a payment intent to also create a subscription and there the recurring payments will be handled by stripe?

sacred depot
#

and i could use a payment intent to also create a subscription
it's the opposit. first you create the Subscription, and then it will contain a PaymentIntent or SetupIntent.

mortal thorn
sacred depot
#

same idea:

  • user enter their payment details
  • then you create a Subscription, that will contain a PaymentIntent or SetupIntent