#jayamini_async-checkout-subscriptions
muted caveBOT
👋 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/1305548583105204316
📝 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.
- jayamini_code, 4 days ago, 16 messages
- jayamini_testing-async-pms, 4 days ago, 40 messages
- jayamini_webhooks, 5 days ago, 6 messages
leaden etherBOT
vagrant wing
Hi there 👋 taking a look, but I believe this is expected behavior.
warm dawn
thanks!
https://docs.stripe.com/testing#send-transaction-emails-in-test-mode
this test payment was created with pm_usBankAccount_processing to re-create an issue client had in live mode.
vagrant wing
Yeah, as far as I'm aware, it's not possible to cancel an intent created by a Checkout Session. And I'm not spotting a way around that. Can you tell me more about the scenario you're testing/trying to handle? Maybe there's a different way to approach it.
warm dawn
The issue we currently have is not tracking async payments in processing state this caused users to buy the same product again while async payment is processing. we had few discussions regarding this here and decided to have a pending state on our side to prevent new purchases while async payments are processing (like U.S. Bank payment).
we are trying to figure out if there's a way to cancel such payments so we can give users the option to cancel them if they choose.
vagrant wing
As far as I'm aware there isn't a way to cancel them.
warm dawn
thanks!
we'll go with to notifying users to wait till the payment is finalised.
There's another issue we faced with using async payments with subscriptions.
Question:
We need to limit customers to one active subscription per product, or at least restrict further subscription attempts until any pending payments for a subscription are finalized. We need to allow customers to subscribe to multiple products but prevent duplicate subscriptions for the same product when a previous subscription payment is still in processing.
we had this issue with delayed notification payment methods, specifically U.S. Bank payments.
is there a way to handle with stripe API or If we need to handle this on our side, could you advise on How to identify when a subscription payment is still pending, specifically for delayed payment methods?
We’re currently listening to events: customer.subscription.created, .updated, and .deleted
We have already attempted:
We tried to limit user to one subscription from stripe dashboard( this doesn’t allow users to subscribe different products )
https://docs.stripe.com/payments/checkout/limit-subscriptions
finally we tried using the stripe subscription object incomplete status as pending on our side and blocking further subscription attempts until the status changes. would it be safe to do this to limit subscriptions?
vagrant wing
Maybe, does that work in your testing? Offhand I'm worried it won't, because I believe subscriptions go into an active state for async payments.
warm dawn
Maybe, does that work in your testing? Offhand I'm worried it won't, because I b...
yeah, in test mode subscriptions are in incomplete state until verification. we were able to catch this as pending.
we were already blocking active subscriptions but somehow users were able to re-subscribe while async payment is processing and before it went to active state. this is the scenario we want to prevent.
are we missing another state here?
vagrant wing
I don't think so, unless you have trial periods or something. Do you have an example of a Subscription that your logic didn't catch?
muted caveBOT
jayamini_async-checkout-subscriptions
warm dawn
I don't think so, unless you have trial periods or something. Do you have an exa...
no trial periods, and I don't have a subscription ref at the moment. this was processed later.
we'll re check this logic
thanks !