#gizmo-help

1 messages · Page 1 of 1 (latest)

royal saddle
#

that might work. It's just not code I'd use/write personally

tranquil geyser
#

To be sure, you would write all of the order data to a pending_order table but then put the pending order id in a cookie for the user for the redirect scenario, and create the PaymentIntent with the pending order id in meta data so you could query for it from Stripe on the webhook side?

royal saddle
#

yes

tranquil geyser
#

Got it, thanks. Is there anything inherently wrong/dangerous about keying off the PaymentIntent client secret instead?

royal saddle
#

I would key off the id at the very least, not the secret

tranquil geyser
#

Ok I'll see if I can get it it by referencing $paymentIntent->id instead of $paymentIntent->client_secret

tranquil geyser
surreal moat
#

nothing really

#

it never gets to the else

tranquil geyser
#

Thanks for confirming, Alex

#

I should be able to just leave it off in that case, correct?

surreal moat
#

if you're planning to always redirect, yes you can leave it off

tranquil geyser
#

Is it a better practice to always redirect?

surreal moat
#

There's no right or wrong answer here, it's more of a case of design preference. There are certain payment methods that will (always) redirect though.

tranquil geyser
#

I figured if I always redirect I'd be positioning myself to handle every payment method.

surreal moat
#

makes sense to me. Otherwise you would have to handle both scenarios of not redirecting, and redirecting

tranquil geyser
#

The biggest change for my app with implementing Stripe is instead of creating orders once I synchronously know a payment was successful, I have to save all of the order information as a pending order prior to stripe.confirmPayment being called and then convert the pending order to a real order upon the redirect if and when the stripe.confirmPayment is called successfully (or when I receive the webhook, i'm trying to set it up it to work idempotently so I won't need to wait for webhooks but they will work). One concern is I'm going to have many pending/abandoned orders in my system this way. Do you know how most applications deal with this or have any best practices to suggest?

surreal moat
#

there's a lot of questions packed into this. Firstly, what do you mean by you're trying to set it up to work idempotently so you won't need to wait for webhooks?

#

ah okay, looking back at the previous conversation i see what you're trying to do now.

tranquil geyser
#

Yeah sorry. So because my checkout was previously synchronous w/ Braintree - customer posts payment details and I do everything on the backend - I was able to determine whether they'd paid server side and take them right to where they need to go. In order to take the customer where they should go while doing it on the client side, I can't wait around for the webhook e.g. email the customer once I receieve the webhook and provisioned them. So I'm going to convert the pending order to a full order upon the redirect, but have the webhook setup to do the same if the webhook comes in and the pending order associated with the payment intent hasn't been converted to a full order yet. That's what I mean by idempotent.

#

Does that still sound like a reasonable approach?

surreal moat
#

hmmm, gimme a few minutes to think about this

tranquil geyser
#

ok sure

#

The whole asynchronous thing is really a world of hurt for me, I wish there were a reliable way to collect the payment details on the frontend and submit them to Braintree on the backend/server when the payment form is submitted, and then process/provision things accordingly

surreal moat
#

the redirect and stuff is fine. Regarding the pending/abandoned orders - i think most users probably ignore it? you can always setup a cron job to cancel (and/or remove them from your DB) them if you want to

#

is there a reason why you didn't use Checkout instead? and are using the Stripe Payment Element

tranquil geyser
#

Yeah basically so the checkout flow is integrated into my site/application

surreal moat
tranquil geyser
#

CurrentIy I collect info from the user on the payment/checkout page. With the previous sync flow I would create their account upon successful payment. I wouldn't be able to collect any of that info with Stripe Checkout, I'd need to collect it on a prior page, correct?

surreal moat
tranquil geyser
#

Thanks. Is there anything bad about using the payment element? I'd have to save all of my order details to a pending order before sending the user to the Stripe Checkout the same way I would with the payment element async flow, right?

surreal moat
#

nothing bad about using the payment element. The payment element allows a greater degree of customisation. Checkout requires less work largely because the UI and a lot of validations etc are already built for you, but of course and correspondingly, you can only customise a limited number of things

tranquil geyser
#

Makes sense. It looks like I have the confirmPayment with redirect working. Can you please remind me what I need to do if my checkout consists of both a one-time charge and the creation of a subscription?

surreal moat
#

as in, how to create a Checkout Session for a one-time charge and subscription?

tranquil geyser
#

Yeah so right now I have the scenario where the customer only adds a one-time charge product on my site to their "cart" working. I have an optional subscription add-on, and if the customer selects it I need the same PaymentIntent to both make the one-time charge and create the subscription/

surreal moat
#

Checkout works using Products/Prices. You would first need to create a Product and Price for the charge product and the subscription add on.

Then after you know what the customer has chosen, create the Checkout Session for those prices.

It will show as a single PaymentIntent. But i think you may likely need to change your logic if you use Checkout due to some differences in how Checkout works

#

are you using Stripe for your subscriptions as well?

tranquil geyser
#

Sorry I didn't mean using Stripe checkout, I meant from my checkout page where I'm currently using Stripe Elements

#

I was using Braintree for everything and am trying to refactor my application to use Stripe

#

So basically the credit card/payment info I capture on my purchase page (I won't call it checkout since that could cause confusion with Stripe Checkout), I need to use that to pay for both a one-time charge and create a subscription

surreal moat
#

have you implemented the logic to create a subscription yet?

tranquil geyser
#

I created a subscription "product" in the Stripe dashboard/admin panel

#

That's as far as I got - I was working on the scenario where the customer does't choose the subscription based addon at purchase time first

surreal moat
tranquil geyser
#

Thank you. Does this explain how I can add a one-time charge at the same time?

surreal moat
#

for the one time charge, you would add it as a Price to the subscription too

#

let me try and find the guide for that, onesec

tranquil geyser
#

Thanks

#

Thanks, I'm not sure that model quite fits but I'll read this over. I need to get to sleep, I really appreciate all of your help.

surreal moat
#

ah yeah, actually you're right, that doesn't exactly answer your question. Let me just delete that link.

In short, what you'd need to do is include a one-time price and a recurring price when creating the subscription.

feel free to reach out again tomorrow!

tranquil geyser
#

Thanks, Alex. I really have to go now. If you're able to find a link that described how to do that and throw it here I would very much appreciate it! Have a great day/night.

surreal moat
#

hmmm, unfortunately i can't find any link that describes how to do that, but feel free to reach out if you are having trouble figuring out how to do it