#pickle-ball_unexpected
tepid nacelleBOT
👋 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/1240065118671474698
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hexed field
This is the relevant snippet from the stripe support reply:
raw holly
Hi there
hexed field
again to reiterate, I'm not trying to use setup_intents, I replicated the error by manually creating a subscription on my dashboard from on imported card and it still created a setup_intent
raw holly
cards I migrated into stripe from paypal
Did you work with our Migrations team on this?
hexed field
yes, they said they were looking into it but it's been 3 weeks since the conversation started
raw holly
You can share an ID here. Do you have a SetupIntent ID?
raw holly
Typically, during a migration, migrated cards are added to Stripe as PaymentMethods
hexed field
Could it be a bug with the import / migration? because customers that are paying through our stripe integration are showing payment_intent's on their payment methods (ex: pm_1P94EoJeB1dEYfoDPdvA4Kn5 , pi_3P94DlJeB1dEYfoD0p8gu8h1) vs. all imported customers from paypal with imported payment methods, from what I can tell, are showing setup_intents when we create subscriptions, whether we create them via the API or via the dashboard.
Other examples:
via api:
pm_1OtG2RJeB1dEYfoDjWNhxMlB ; seti_1OuMtZJeB1dEYfoDo7AHBYL1
pm_1OtG2VJeB1dEYfoD1Bc5hl54 ; seti_1OuMtbJeB1dEYfoDK78HHUkY
via manual subscription creation in the dashboard:
pm_1OtG2fJeB1dEYfoDnp3szMik ; seti_1P3g4CJeB1dEYfoDiMeu4Mvu
pm_1OtG2kJeB1dEYfoDoHj5hBCN ; seti_1P46eiJeB1dEYfoD0xA0CQcg
this is copied and pasted from a prior email
and to clarify, the cards are payment methods, but when I create a subscription it's creating setup_intents
it's a bummer because I have people passing zip and street check and they're still being declined
raw holly
SetupIntents are being created since a payment is not being collected immediately for the subscriptions where you're passing billing_cycle_anchor with a future date
hexed field
That makes sense, since I wanted to have all the subscriptions active in stripe and then charge customers on their renewal date
but the support person said I wasn't supposed to do that?
to use setup_intents
the root cause I'm trying to solve is why amex is declining every transaction, I'm not sure if it has to do with this or not
raw holly
The declines seem orthogonal to this
hexed field
OK, it was the only other thing I noticed that was different between new customers and imported customers
I'm using setup_intents correctly though?
raw holly
I'm not sure this is possible:
I wanted to have all the subscriptions active in stripe and then charge customers on their renewal date
hexed field
I think I said the wrong thing, I want the subscriptions "setup" in stripe
raw holly
Since active means a payment has been collected for the current billing period
raw holly
Actually, hold on.
hexed field
oh boy
raw holly
I see you're essentially doing this via the API: https://docs.stripe.com/billing/subscriptions/backdating#backdating-billing-cycle
hexed field
yep but not charging them
raw holly
Which is setting the Subscription to active but not immediately invoicing a customer. This is fine if that's what you want to do: charge the customer on the billing cycle anchor date for the next billing cycle + the proration between the backdate start date and billing cycle anchor
hexed field
I know I didn't charge them though
I think I did it this way https://docs.stripe.com/billing/subscriptions/backdating#backdating-no-charge
raw holly
you did, that's correct
Sorry for missing the proration_behavior: none in your request
So yes, we automatically create a SetupIntent when a Subscription is created that does not create an initial payment
hexed field
OK so that's the intended behavior - but that's not impacting decline rates?
raw holly
Right, orthogonal in this case.
Do you have the ID of a PaymentIntent or SetupIntent that was confirmed and resulted in a decline?
hexed field
yeah
one sec
cus ID is cus_PihROLEHVQLOzb I'm trying to load the original setup_intent
seti_1OuNZoJeB1dEYfoDyGqxldSi
now I can see in the logs "An attempt to set up pm_1OtG33JeB1dEYfoD4pCe1Fq2 via SetupIntent seti_1OuNZoJeB1dEYfoDyGqxldSi has failed"
here's one that succeeded: seti_1OuN6hJeB1dEYfoDuK2FAFaK
and still resulted in a decline
the cc was expired though, let me see if I can find a good one
Here's another one: seti_1OuNQ6JeB1dEYfoDpQUp2SMa
also all of the amex declines are do_not_honor and then eventually stripe blocks the attempts
unfortunately a lot to choose from 😦
raw holly
I don't quite follow this:
here's one that succeeded: seti_1OuN6hJeB1dEYfoDuK2FAFaK
and still resulted in a decline
Where exactly do you see the decline?
hexed field
oh
one sec
pm_1OtG2jJeB1dEYfoDZsriY30g
^that's the pm connected to the setup_intent and it resulted in failed payment / payment_intent pi_3PFrwaJeB1dEYfoD1bDCbuu7
raw holly
Thanks!
So yes, when subscription sub_1OuNQ5JeB1dEYfoDSOt1RCij was created, it was created with a billing_cycle_anchor date of May 13. When May 13 arrived, we attempted a payment using the payment method you used when creating the subscription. That's where the PI comes in and the attempted charge that ultimately declined
The issuing bank replied with a do_not_honor decline code: https://support.stripe.com/questions/decline-code-do-not-honor
This can happen even though the cards were used with Paypal for previous recurring payments
In terms of next steps, you can have this customer contact their bank to determine why this was declined, and also bring the customer back on session so they can provide their card details via the PaymentElement. You can use the PaymentIntent's client_secret to render the PaymentElement
hexed field
thanks - so it seems there's nothing wrong tehnically that's causing them? I called amex and they said they'd be happy to investigate but there's only one amex team that's allowed to work with stripe's data, do you know the easiest way to get someone at stripe to reach out to that team?
raw holly
Customers will need to reach out to Amex directly to address these declines, you won't be able to do this on their behalf
The fastest way to recover from this is, if a subscription payment fails (which is happening now for some migrated cards but could happen for any number of reasons in the future with other non-migrated cards), you will need to bring your customer back on session so they can provide card details again and you can confirm the PaymentIntent with those new card details
hexed field
yeah that makes sense, amex said they'd look into it the do_not_honor declines too but it's stripes data so they need to work with stripe to look at them.
if I get a customer to reach out to amex and they say the same thing, then would stripe work with amex to share the data?
raw holly
What data exactly?
Declines like this are normal, especially after a migration where an issuing bank will see charges coming from somewhere new (Stripe in this case)
hexed field
yeah that makes sense, but it would be nice to have a way of notifying the bank they're coming from stripe legitimately through an import
does the migration team do anything like that? I assume that's what amex would look into if they had access - they'd realize that the declines are probably because of the processor move and update their system
raw holly
If you still have a support thread with the migration team, that would be a question best suited for them.
hexed field
got it, it's too bad they don't have a discord because their average response time is 10 days
thanks for your help though this has been really helpful
raw holly
Happy to help!