#phrygian2433
1 messages · Page 1 of 1 (latest)
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.
- phrygian2433, 2 minutes ago, 2 messages
Hello again! Yes, if you continue to use legacy Checkout any payment that requires 3D Secure will fail. There isn't really any viable path where you can continue using legacy Checkout, it's very old and very much not recommended at this point.
We have a migration guide from legacy to new Checkout here: https://stripe.com/docs/payments/checkout/migration
Thank you. I will discuss migrating to the new checkout with the team.
In the meantime, I have another issue that we encountered.
In the screenshots, the subscription was initially incomplete and later canceled after 24 hours, that is what I believe has happened. My question revolves around how the payment succeeded despite the incomplete subscription. Moreover, if the payment was successful, why wasn't the subscription completed or marked as active afterward?
I can't figure out the root cause of this.
Can you give me the Subscription ID from the first screenshot and the Customer ID from the second screenshot?
Yeah sure. This is our live customer. The subscription Id is sub_1Nrhr1AHWqQYWrG1hLDKgjKV
And the Customer ID?
The Payment Intent ID for the successful payment would also work.
Customer ID: cus_Of1u0CVXpTKiDk
The successful payment in your screenshot was made with a direct call to /v1/charges in this request, and has nothing to do with that Subscription: https://dashboard.stripe.com/logs/req_0YPKYldWBtBMDI
In our payment workflow, we initiate the process by creating a customer, followed by the creation of a subscription, and ultimately conclude with the generation of a charge. However, I've observed that the only validation for proceeding with charge creation is the presence of the subscription Id. Despite meeting this condition, if the payment is completed or the charge is created, why doesn't the subscription become active?
could you review this code?
Okay, there are several issues here. First, you should not be creating both a Subscription and a Charge. Subscriptions create Invoices, and Invoices create Payment Intents, and Payment Intents create Charges, so you creating a Charge separately is redundant. Further, creating Charges directly is deprecated and not recommended.
Backing up a bit, what's your use case? What are you trying to build?
The project aims to help tenants resolve housing disrepair issues with their landlords. Customers typically subscribe to monthly or annual packages, as they are primarily renters.
Could you please suggest a more efficient method that aligns with the recommended practices? We are eager to optimize our approach.
If you're only dealing with recurring payments you should only use Subscriptions and not create individual Charges.
That's the biggest recommendation I have for your flow.
Okay. Thank you Rubeus.
Happy to help!