#bjsbx_webhooks
1 messages · Page 1 of 1 (latest)
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1255245111542022164
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
Hello
Is there a specific reason you're using manual confirmation? Just want to make sure I am on the same page
No. I think this was just our understanding on how confirmation works.
When using the Stripe SDK on react native, does the UX handle confirmation? If not, are there implemtation guides on how to handle payments that require it?
From the client side, via Stripe react native SDK, how do we know if a payment intent requires confirmation? Do we need to the client to call stripe to figure that out per payment intent?
The ReactNative SDK should handle client-side confirmation, yes. But the PaymentIntent should only enter requires_confirmation status if you're setting confirmation_method: manual when creating the PaymentIntent.
https://docs.stripe.com/api/payment_intents/create#create_payment_intent-confirmation_method
Can you share example API requests so that I am on the same page?
Sure, ill need a minute.
I cleaned this up a bit to remove some unnecessary metadata. But this is how we generate our payment intent in node. We don't pass confirmation_method explicitly as I believe the default is automatic anyways.
paymentIntent = await this.client.paymentIntents.create({ amount, currency, customer, payment_method_types, setup_future_usage: "on_session", });
We in turn pass back an empheralKey and publishableKey back to the client. The client uses initPaymentSheet via the Stripe sdk on react native.
Am i correct to assume the server should be setting requires_confirmation?
The crux of the issue we're seeing is when some users pay via ACH. Then it gets stuck on requires_confirmation.
Can you share a request ID for these stuck payments?
https://support.stripe.com/questions/finding-the-id-for-an-api-request
Or even PaymentIntent IDs should work too i.e. pi_xxxx
I don't have a stuck one atm, but i can see if i can find the the few that got stuck in the last week
Yup, if you don't find one then any random PaymentIntent ID would work too
Is it safe to pass a PI id in this chat?
yup, it is safe
pi_3PNO9LJhkqgFUbV21jHF4ZDz
It's not currently stuck as we've confirmed it. But at one point it was stuck and user couldn't continue.
It doesn't look like it was in requires_confirmation status. However, it was in requires_action status.
Is that what you're referring to?
It was in requires_confirmation at one point
"status": "requires_confirmation",
This is another payment intent pi_3PLq5lJhkqgFUbV20F0m2Naz
Oh interesting... taking a look
So my original plan was to try to implement a requires_confirmation status from a webhook on the server side. So we can relay that back to the client. But just found today that stripe doesn't support returning requires_confirmation. Well at least per the SDK. Not sure if the rest api does. Preferrably the Stripe React Native SDK would handle allow the user to press "confirm", but that's where we are unsure of on how the recommended flow.
Looking in to this. I am fairly certain that requires_confirmation happened here because a payment method was attached to the intent but the intent wasn't confirmed. That can only happen through a server-side API call, so the response with the requires_confirmation status would be the signal for that status.
I see
I guess my next question is, how can my server know the status of the payment intent without retrieving each one. I don't think the webhook returns a requires_confirmation status. Correct me if i'm wrong here.
As far as I can tell, outside of the manual confirmation flow, these intents should only go in to a requires_confirmation state as the result of an API call that your server makes. So it would get that status back as part of the response to that API call
This specific payment intent went in to a requires_confirmation status as a result of a CLI command but in live that would be made by your server. https://dashboard.stripe.com/logs/req_j6PgUiWE2NwWOG
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Our server generates the payment intent but our client intiates the api call for the transaction. At the moment, our server is just waiting for webhooks.
Via the React native STripe sdk
I'd have to double check, but we only started using the CLI to get PIs out of requires_confirmation.
I actually don't see any attempts to confirm that payment intent from the react SDK, only the CLi
Can you make another payment intent, confirm it through your react app, and send me the ID so I can take a look?
I'm not sure how to generate this type of status. But to clarify, I don't know how to get the client to confirm the payment intent.
Via the SDK
So this status happened when someone on your account attempted to confirm that intent via the CLI but got an error because mandate_data was not supplied when it was needed. That is the request that I linked to
Ah so you haven't been testing on these payment intents with the react SDK at all yet?
These actions happened after we found a stuck confirmation
That intent was not in a requires_confirmation status until that API call.
We have been testing we're not able to test this particular scenario as I'm not sure how to get into a requires_confirmation state
I see
Even this payment intent @craggy wharf ? pi_3PLq5lJhkqgFUbV20F0m2Naz
I'm can regroup and reach out if or when this happens again. So I can be sure I'm not affecting the PI with the CLI.
That PI got to that state a different way. Checking in to this
Ok ty.
I do actually see a React SDK action moving this intent in to that requires_confirmation status but it doesn't look like a confirmation. Can you send me your react code for confirming these intents?
Checking
Ok I cleaned up some more identifiable data if you don't mind. But this is the gist of it. We don't explicitly handle the confirmation to be clear. We have no code for it. If that's not right, then we can fix that.
await initPaymentSheet({
appearance: customAppearance,
merchantDisplayName: "INC",
customerId: customer,
customerEphemeralKeySecret: ephemeralKey,
paymentIntentClientSecret: paymentIntent,
allowsDelayedPaymentMethods: payWith === PayWith.Ach,
returnURL: "www",
defaultBillingDetails: {
name: "name",
email: emailAddress,
address: {
country: shipToCountry,
},
},
defaultShippingDetails: {
name: "name",
email: emailAddress,
address: {
country: shipToCountry,
},
}
});
Ah interesting. I got to the same place with a PaymentIntent by selecting an ACH bank account in the payment sheet but not confirming the intent
Reading this documentation i see this bit. https://docs.stripe.com/payments/accept-a-payment?platform=react-native&ui=payment-sheet
Setting allowsDelayedPaymentMethods to true allows delayed notification payment methods like US bank accounts. For these payment methods, the final payment status isn’t known when the PaymentSheet completes, and instead succeeds or fails later. If you support these types of payment methods, inform the customer their order is confirmed and only fulfill their order (for example, ship their product) when the payment is successful.
But not sure what to do afterwards if this is a delayed method.
This is, but this behavior is slightly different than that. That exerpt is talking about the pending status for intents. So here is the current lifetime of one of your intents that takes an ACH payment:
Gotcha. Yea when it goes from pending to succeeded we can get the events back from webhooks. So we can act accordingly.
- The intent is created on your server, it starts in a
requires_payment_methodstate - The customer chooses a bank account to pay with on their phone, that account is associated with the intent, moving it to a
requires_confirmationstatus. - The customer clicks the "Pay" button on the payment sheet, the intent goes in to a
processingstate while we wait for the bank's response, which can take days in live mode. - Once stripe hears back from the bank, the intent moves in to either a
succeededorrequires_payment_methodstate depending on whether the charge succeeded or failed
So with the intents that you are seeing in requires_confirmation, as best I can tell the payment process was started on your app but not finished. I think that that may be invisible and am honestly not sure why we change the status and surface it to you like that.
I believe there's an optional step between 2-3 where after it is confirmed, it may require_action such as verifying micro deposits. What I've had to do recently is confirm the payment,from the cli, then the buyer still has to do a micro deposit usually.
Good catch! That is exactly where it would happen
The hard part is how do we surface this to the user so it's obvious it needs to be confirmed. The SDK is a black box for this scenario to me since I can't actually test it. At least as far as I know.
Also, it feels icky "confirming" a payment for a buyer. It seems they should be confirming it.
Even if hypotehtically I can get the server to reliably catch confirmations and confirm them automatically
I think in this case you don't have to do that. Our sheet shows that they still need to submit the payment, this is more of the customer wandering of for some reason
Agreed, you shouldn't confirm these intents for them.
I see
Requires action it might make sense to watch for because the user did submit the payment at that point, but that depends on your preference.
I see, Though the PI won't get to requires_action before the requires_confirmation. From my observation, only after the PI is confirmed does it move to requires_action.
Exactly, sorry sounds like my wording was off there. requires_confirmation is a before the confirm status and requires_action is an after the confirm status.
Ok so in theory, the Stripe React Native SDK should show the user the "pay" button to confirm. But in our scenario, this step may be not completed by the buyer.
Exactly. It looks like these statuses were reached by getting to this screen after they have connected their account
Also the PI lifecycle goes from processing to requires_confirmation. I'm not sure how to get the buyer to confirm after they potentially backed out the first time. If it ends up in requires_action, we reviceive a webhook and it even has a hosted url for micro deposits. So we can surface that on the UI. I feel ike if a payment intent goes to requires_confirmation and doesn't complete, we cancel it?
As far as I know, PIs can't go from processing to requires_confirmation , do you have an example of that happening? processing should only happen after the intent is confirmed
That is a sensible way to work with requires_action, and I would say treat requires_confirmation the same way as intents staying in requires_payment_method for two long. It is an abandoned card after some point so you can cancel them if you clean those up.
You're right. I got confused.
Your advice makes sense. I think the last thing though is that webhooks dont seem to return requries_confirmation? Am i wrong in that?
You are correct there. So I don't think you can get notifications about them. How have you been finding these, listing by status?
searching via CLI
Seems clunky
We'll I think I can manage. Appreciate the help. I have a better understanding of the flow.
Yeah, if you want to clear out abandoned carts it may make sense to either keep a record of all of your PIs and then cancel them if you don't get a succeeded event for them, or you can preiodically list payment intents by the requires_payment_method and requires_confirmation statuses that were created before a certain date.