#rodney-intents-element
slow crater
Hi there!
Not sure which documentation you're referring to right off the bat
That said, you might find this integration flow useful: https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription
You can render the PaymentElement before creating a Subscription (and having an intent client secret to work with)
timber canopy
Gotcha. Is there a simple way of checking if a customer has an existing subscription on the client side? Something similar to the feature in the Checkout product (https://docs.stripe.com/payments/checkout/limit-subscriptions)
Our use case doesn't allow us to use Checkout or Sessions unfortunately
slow crater
No, this can't be retrieved client side. If you add some sort of authentication piece to your app, you can have some logic on your server end to determine whether that particular customer from your app has a corresponding Stripe Customer object (with or without a subscription)
timber canopy
Makes sense. Sounds like the best thing for our use case (since we store subscription and subscription item IDs in our db) would be to return a special case in the event of an "active" subscription with pending setup intent
from our server
does having the client secret in an active PaymentElement (customer is still in the initial session) give access to the status of the intent?
slow crater
What do you mean by "give access"
timber canopy
See updates to the status of the intent. On subscription creation, the status is requires_payment_method and then let's say bad card info was put in, presumably the status becomes requires_action
slow crater
I recommend testing this out. If a customer uses an invalid card number client side, the intent's status will remain requires_payment_method
We'll return an error client side if something goes wrong with confirmPayment or confirmSetup and it's up to you how to display the error
timber canopy
oooh yes that is the scenario I'm most interested in, sorry for not wording it better!
is an error from confirmSetup recoverable from the client?
*and using the same client secret
slow crater
Yep, that's visible client side. confirmPayment and confirmSetup will return a promise. If confirmation fails, the promise will resolve with an error
I recommend playing around with the example in our quickstart guide to get an understanding of this: https://docs.stripe.com/payments/quickstart#handle-immediate-errors
timber canopy
Yeah what is the recommended (if there is one) next step in the state machine if confirmation fails? More or less display an error message and collect new details in the same payment element to try again?
slow crater
Yep, display an error message that prompts your customer to try again. The PaymentIntent will still be in a non-terminal state (should still be requires_payment_method) so a customer should be able to retry using a new/different card number with the same PaymentElement
No need to create a new PaymentIntent or have them refresh or have you unmount/remount the Element
slow crater
Sure thing, happy to help!
twilit rapidsBOT
rodney-intents-element