#cho-productcatalog-paymentintent

1 messages · Page 1 of 1 (latest)

clever shadowBOT
#

Hello! We'll be with you shortly. 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.

  • _cho, 17 hours ago, 5 messages
tepid lion
#

cho-productcatalog-paymentintent

#

@faint cloud no, the PaymentIntent API does not support Products and Prices so there isn't really an advantage in this flow I would say.

I would build your integration differently personally though. I'd never do a SetupIntent now to then do a PaymentIntent after a manual review. I would do the PaymentIntent upfront with manual capture so I can hold the funds while I review the order and decide whether to approve it or not

faint cloud
#

I spoke with support as well as a stripe representative, and it was decided to do a setupintent >> paymentintent understanding that it might be more prone to payment failures because it is more customer-centric. Is there a specific reason you would not do it this way?

#

We did not want to show the customer a payment hold on their card at all.

#

The concern is that the products we are offering are too expensive + we tell them we will not charge them until after approval

tepid lion
#

because of payment failures. Much much harder to get your customer back on session to pay again. Like when I order on Amazon and my payment fails I go back, any other website I go "well wasn't meant to be"

#

we tell them we will not charge them until after approval
I mean you tell them that so you could change that

#

Up to you, your flow works, just not what I would do

faint cloud
#

That makes sense. I understand the risks and difficulties of the flow we have. I'll make note of it for when the decision making comes up

#

However, there is no overlap between the product catalog IN STIPE & the paymentintent system

#

correct?

tepid lion
#

correct

faint cloud
#

one moment let me search the API real fast

#

If I am making subscriptions, and I wish to charge the customer a different (discounted) value and then charge them a subscription afterwards, it would be wisest to just keep the payment intent, charge it, and then make a subscription that will be charged in 1 unit of cadence. Is that correct? Or do you see a better route

#

Essentially,
Customer makes order > Puts card down >
Approval done > PaymentIntent made + charged > On success of paymentIntent > Make subscription > Subscription payment date is in 30 days (if monthly)

tepid lion
#

That works yes. But you can also use SubscriptionSchedules to have 2 phases, one for the first amount paid and one for the normal recurring price after that. Up to you really

faint cloud
#

Oh, in that case that you mention, would I not have to make a paymentIntent but use the SubscriptionSchedule only?

tepid lion
#

yes, that way you get a real Subscription, each payment has an Invoice, you can calculate MRR and churn, etc.

faint cloud
tepid lion
faint cloud
#

aha! thank you. I'll investigate this and move forward.

I had a small question based on what you had said, "each payment has an Invoice" in regard to the subscriptions.

Do paymentIntents that succeed not have an invoice?

#

automatically*

tepid lion
#

correct they do not