#broken_intent-status

1 messages · Page 1 of 1 (latest)

late nexusBOT
#

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

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

crimson pollen
#

👋 Those first two states are not actually terminal, they're intermediary states indicating further steps are necessary before a charge can be attempted, and in the last case, if the Payment Intent is cancelled (which is terminal) a charge would not be attempted.

#

Can you clarify, are these failed payments from a recurring subscription?

austere imp
#

Oh okay, so with the first two states, the customer would be prompted to like verify or authenticate -- meaning a webhook event would eventually come out of it?

crimson pollen
#

Correct, requires_action most commonly in the context of card payments indicates the bank requires 3DS authentication to complete which requires the customer to be on sessions to perform.

#

requires_payment_method likewise the card was rejected and thus never attached, and set to that state so that the customer can try again with new payment details.

#

Generally if the payment method was succesfully charged and saved with setup_future_usage and then fails at a later subsequent charge say the next month for a recurring subscription scenario. Attempting to retry makes sense. However if this was the first attempt with a given Payment Method and the Payment Intent failed, retrying with the customer not on sessions is a somewhat fruitless endevour.

austere imp
#

Okay gotcha

#

Right now, we are only doing retries for just invoices

#

not like subscriptions or anything

crimson pollen
#

That make sense, well say it's the second invoice from a customer with a saved payment method that has succeeded before, and it fails for some reason, still possible a retry might succeed, especially if it was an insufficient funds scenario, but in the situation above where say it's not a card that was saved before, that card needs to complete a Payment Intent, or Setup Intent with the customer on session before it could be retried off session.

#

Is there a reason you are not using our automatic retry system?

austere imp
#

I don't exactly remember but I think it has to do with retries only being stored for 14 days or something in stripe?

#

wait nvm, one second, let me ask

crimson pollen
#

Our smart retries system will allow 8 retries in up to two months I believe.

austere imp
#

Can subscriptions in stripe change amounts each cycle?

crimson pollen
#

yes they can

austere imp
#

Do you know how we'd go about setting that up?

crimson pollen
#

if you have a little more use case context I could help you zero in on the right information.

shut jasper
#

We have a living list of equipment for trucking companies, the list of active VINs changes month to month, and we pro-rate the first month

Every subsequent month, we run algebra to calculate total invoice for active list of equipment at the moment of execution on first of the month

We would want to have this updated invoice amount charged automatically if we used stripe subscriptions here, and the auto card retries

crimson pollen
#

Does this end price end up being a single line item or multiple?

shut jasper
#

We’re splitting across 3 line items bc we heard 200 line item limit on invoice obj

#

The 3 line items are:

  1. connect account net

  2. Application fee (us)

  3. Stripe fee (you

crimson pollen
#

So you could continue to run your normal calculations and update the subscription with inline price data rather, than fixed prices. Something like:

stripe.subscriptions.update(subscriptionId, {
items: [{
id: subscriptionItemId, // existing sub item to update
price_data: {
currency: 'usd',
product: 'prod_XXXX', //name for the product would determine the line item name.
recurring: { interval: 'month' } // required for subscriptions
}
}],
proration_behavior: 'create_prorations'
});

I'm just trying to think if migrating this way is more or less work than building your own retry engine which would require you basically considering all the different kinds of declines and and possible errors, and reacting to them accordingly. I suspect an in house retry engine would still be more lift.

late nexusBOT
warped rapids
#

broken_intent-status

shut jasper
#

Thank you! We’re wrestling with best path forward rn

austere imp
#

Is there a way to get all charge objects associated with an invoice?