#seth_error
toxic stoneBOT
👋 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/1374221487493484554
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fossil flint
hello! you shared a link to the release page, can you share a link to the issue you logged in our github repo so that I can take a look?
valid mesa
fossil flint
okay, so it sounds like you reached out to us too on Discord? was this the last conversation you had with us about the issue : #1344701533849256048 message
valid mesa
Yup that's the last chat we had. Was told to open the github issue so it can be better tracked, which was subsequently closed
fossil flint
hmmm, gimme a while to take a look
raven pumice
Hi @valid mesa I'm Jack, and I also an enginer from Stripe.
Can you tell me what error message you get from the Stripe SDK when you call intentCreationCallback({clientSecret: response.clientSecret}); ?
valid mesa
Yeah one second, I believe there isn't actually an error message and when the intentCreationCallback is called with the returned clientSecret, it is never resolved and just perpetually loads. Eventually, the Apple Pay bottom sheet logs a failure. I can verify this in a bit.
raven pumice
Thanks.
valid mesa
From my server side, the payment intent is correctly generated and I get a valid clientSecret back. When the intentCreationCallback is called, the following happens:
- Loading (SS 1)
- Failure (Apple Pay Only) (SS 2)
This catch block does not log an error, and the code advances past intentCreationCallback({clientSecret: response.clientSecret});
await bookRide(user, selectedRide, currentSegment, paymentMethod.id)
.then((response) => {
intentCreationCallback({clientSecret: response.clientSecret});
setLoading(false);
setShowBookingSuccessDialog(true);
})
.catch(error => {
console.log('error: ', error)
setLoading(false);
// intentCreationCallback({error: {
// code: 500,
// message: error,
// localizedMessage: error.message
// }});
})
};
If I use a standard credit card, no visual errors are presented and the flow works as expected.
toxic stoneBOT
valid mesa
And, as noted in my GitHub issue, the PaymentIntent ConfirmationMethod on the server side is set to manual (Stripe Go):
ConfirmationMethod: stripe.String(string(stripe.PaymentIntentConfirmationMethodManual)),
If I set it to automatatic, Apply Pay succesfully resolves. However, this is not in line with our business logic as we do not want to have to refund the user every time a driver doesn't approve the drive (see screenshot).
raven pumice
Thanks for the details and context @valid mesa does your business require you to place a hold on the payment and capture later?
valid mesa
No we don't want to place a hold. If you are thinking of suggesting this https://docs.stripe.com/payments/place-a-hold-on-a-payment-method, I have been suggested this many times before. It does not align with how the business works.
If a user were to get a success that a hold has been placed on their payment method, and then the hold were to expire before the reservation is confirmed by the driver, it will be way too much of a headache for them to make an attempt to rebook. We would have to ensure that the drivers are reliable enough to confirm bookings within the window. Our conversion rate would fall apart.
That is why we need to create a payment intent and manually confirm it on the server side.
And as I mentioned before, the flow we have implemented works perfectly with a standard credit card. It is only the Apple Pay presents a visual error in this instance when there is in fact no error
raven pumice
Ok. I'd need to discuss with the mobile SDK team and see if this is the flow that we can support with Apple Pay. Can I covert this conversation into a support ticket and continue supporting you through emails?
toxic stoneBOT
Hello @valid mesa, we have sent you a direct message, please check it at https://discord.com/channels/@me/1374244320701321280
- 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
valid mesa
Sure
Do you need my email, the link I was sent is more like common issues and I don't see a way to generate a ticket.
raven pumice
Also I'd like to highlight that with manual confirmation, you need to confirm the payment within 1 hour otherwise it will go back to require_payemnt_method status
You can use the link to reach out to support and they'll create a ticket for you
valid mesa
I just send a message to the chat?
raven pumice
Did you get a link in your DM?
Once you click on the link, you can chat with support and they will create a ticket for you.
valid mesa
Also I'd like to highlight that with manual confirmation, you need to confirm th...
This is all I got.
raven pumice
Yes we've got the ticket
valid mesa
Also I'd like to highlight that with manual confirmation, you need to confirm th...
Is there documentation on this? I have seen plenty of PaymentIntents from our users confirmed days after they are generated.