#Knippy - Payment Intent Data in Subscriptions

1 messages · Page 1 of 1 (latest)

polar summit
tribal herald
#

For clarification, this is for a checkout session

polar summit
#

But you are using Checkout for people to sign up for subscriptions, correct?

tribal herald
#

yes, potentially along with one-off items

#

their cart might have rental options but also might have rental options as well as purchase options

polar summit
#

And when you try to pass in the payment_intent_data object when creating your session you get the error above, right?

tribal herald
#

Yes

polar summit
#

Because you want to use the payment_intent_data.capture_method = 'manual'

tribal herald
# 
apiObject.submit_type = 'pay';
        apiObject.payment_intent_data = {capture_method: 'manual'};

        apiObject.payment_intent_data.metadata = {};
        apiObject.payment_intent_data.metadata.isPreorder = !!req.cart.preorderProduct;
        apiObject.payment_intent_data.metadata.order_number = req.cart.orderNumber;
        apiObject.payment_intent_data.metadata.statement_descriptor = `ActrsBbl ${req.cart.orderNumber}`;
        apiObject.payment_intent_data.description = `Order #${req.cart.orderNumber}`;
#

correct

#

it works for the one-off purchases, but i'm retro-fitting a rental system into our eCommerce application and running into a bunch of architectural issues, including this

polar summit
#

Yeah, I don't think the Checkout Session is going to support a mix & match approach with the payment options you are attempting. But let me do more digging

tribal herald
#

Thank you!

polar summit
#

I'm not seeing the mix and match approach as being viable in the docs but I'm trying to test out my own integration and see which behaviors I get.

tribal herald
#

aye. i'm not sure what i can do then. I might have to make it so a customer's cart can only have buy or only rent at one time

polar summit
#

Hmmm... that bugs me....I'm going to keep reviewing

#

Okay you can do both one-time and recurring items together. But I don't know about using the manual capture method too

tribal herald
#

I mean, i think i understand the reason with the capture method situation. For example, what if you have a subscription that's every 2 days and you havent captured the first charge yet. I can see where that can get out of control with managing the data

#

hey karbi! 🙂

#

my issue is i'm trying to avoid a situation where a customer orders something and turns out we are out of stock. I'd rather cancel the capture rather than refund them and lose that processing fee

#

Plus, and this might be a little over-cautious, but I also want to keep our refunds to an extreme minimum to avoid upsetting Stripe's fraud detection algorithms...

severe zenith
#

👋 Just to make sure I understand right - you have a subscription w/ some physical product (or something similar) that you need to verify you have the inventory for before actually collecting the funds. The solution you're currently looking into is whether you can accomplish this with seaparate auth + capture, right?

tribal herald
#

Yes, so, our current working flow is a regular ecommerce store which works how you'd expect. I'm trying to add in the ability to rent specific items and how I thought to implement that was basically create a subscription for the item itself, and have the subscription canceled when they return the item, that way there is recurring billing during the rental itself

#

Now on the regular purchases, i have it set up for manual capturing of the charge to verify inventory and I think it's in accordance with visa, etc to not capture the charge until the order is fulfilled (i.e., shipped)

severe zenith
#

Just thinking out loud for a minute - instead of separate auth/capture would a flow where you wait to finalize the invoice until you've confirmed that you have the full inventory also work? Alternatively, you may want to just do the first charge of the subscription as a one-time thing, and then wait to create the Subscription until you've confirmed you have the stock

tribal herald
#

Sorry for the delay! i'm dealing with a major network disruption on my client's servers!

#

likely related to the issues discord is encountering

#

Gimme a few Karbi! 🙂

severe zenith
#

I need to head out, but @tough elk 's here to help! Just to leave some extra details before I go:

  • It sounds like you're just worried about checking inventory when the Subscription is created, so you could do a one-time payment w/ separate capture, and then create a subscription (w/ a trial so you skip the first payment) once you confirm that you have the inventory
  • You could also look into creating the Subscription w/ a brief trial so that the first non-zero invoice is not immediately finalized. You can use that 1 hour draft period to confirm whether you have the inventory, and if you don't you can just turn off the auto advancement of the Invoice until you do
tough elk
#

👋

tribal herald
#

Hey @tough elk -- sorry for the delay. i think someone DoS'd my client's server around the same time all services were having issues too as there was a massive spike in traffic and it's resulted in the server hitting 100% cpu usage and i'm trying to resolve it now, but i'll read what miss karbi said in a tiny bit

tough elk
#

Yep, no problem -- good luck resolving those issues!