#dany_docs

1 messages ¡ Page 1 of 1 (latest)

fallen fjordBOT
#

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

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

hasty bane
#

qualifying the doubt:
The way to create a paymentIntent is through the backend, retrieving an ephemeralKey and sending it to the frontend. Then the frontend will show a Stripe form, with the amount and allowing payment.

The way to create a subscription is by retrieving from the frontend, through the stripe API, a payment_method_id, and sending it to the backend. The backend creates the subscription but the user here does not have to accept anything nor is the amount shown, unlike the one-time payment with paymentIntent.

Is this correct? Or is there a way to manage the subscription payment as if it were a paymentIntent?

nocturne oak
#

Hi, let me help you with this.

#

is there a way to manage the subscription payment as if it were a paymentIntent?
Yes. Each Subscription generates a PaymentIntent with a client_secret that can be used to render a Payment Element.
However, I would advice against forcing the customer to type in their payment details twice.
I suggest 2 solutions:

  • Save the PaymentMethod for future usage with a SetupIntent, and then charge it for the deposit, and then start the Subscription with it.
  • Create a Subscription with a one-time deposit item, which will only be added to the first Invoice, and avoid creating a standalone PaymentIntent.

Please let me know which approach you like more and I am happy to go into more detail.

hasty bane
#

I think the second one is more interesting.
Create a subscription and associate it with a one-time payment deposit.
I didn't know this was possible.
I think it's the best option.
Especially since it's just one procedure, not two.

nocturne oak
hasty bane
#

Can you confirm this for me?
I should create a product and price for the deposit in the backend.
Also a product and price for the monthly rental.
And create a subscription based on the monthly rental price, adding the deposit as a one-time payment in something like this:
\Stripe\Subscription::create([
'customer' => 'cus_zzzzzz',
'items' => [
['price' => 'price_yyyyyy'],
],
'add_invoice_items' => [
['price' => 'price_xxxxxx'],
],
'payment_behavior' => 'default_incomplete',
'expand' => ['latest_invoice.payment_intent'],
]);

???

fallen fjordBOT
hasty bane
#

Then I extract the secret:
$clientSecret = $subscription->latest_invoice->payment_intent->client_secret;

And I send it to the front end so the user can confirm the payment.
Is that correct?

real edge
#

Yep, that looks right, so the recurring amount would be based on price_yyy and there'd be an initial added item for amount from price_xxx

real edge