Request receipt event is not firing after the ride is completed.I am initiating ride from ride request button. Scope of request receipt is given full access.
Does the web-hook is fired when ride is initiated from the ride request button?
It looks like the documenation provides an answer here, bolded the potentially relevant part: https://developer.uber.com/docs/riders/guides/webhooks
"requests.receipt_ready Given that your application has access to the
request_receipt scope and has a valid OAuth authorization for a user,
Uber’s server will make a POST request to your application’s webhook
url when the Request Receipt status is available for Requests created
by your application a POST /requests. This will allow you to show your
user the details of their fare and how much they were charged as soon
as their Receipt is available. If the rider cancels after the grace
period, and they are charged, a receipt will be available showing that
charge.
The receipt endpoint will only provide receipts for ride requests
originating from your application. It is not currently possibly to
receive receipt data for all trips."
Related
I am currently integrating Stripe Elements into my ReactJS app. What I am developing is a system in which my users can upload an image to display as an advertisement on my web app for 30 days. This means that a payment needs to update a row in my database with a new expiration date. We are also having the users manually renew each expiration period so we are not using subscriptions.
From what I understand, the flow is as follows for a first time customer:
User goes to the advertisement upload page
The user submits the advertisement form. Client sends POST request to my API server and creates payment intent with NodeJS Stripe SDK
Advertisement is saved into DB with an expiration date of null.
Payment Intent ID is saved to relationship table associating it with the banner
advertisement
Payment Intent secret is sent to client with status OK
Client Secret is given to Elements to show and handle the payment form
Stripe sends the event to my webhook endpoint with Payment Intent ID.
Use Payment Intent ID to find which banner advertisement should be updated with new expiration date
From what I've read on the docs, this flow should work. If anyone notices issues, please let me know!
My question is: can I show the user their next advertisement expiration date right after their purchase? Or do I need to show them "Pending" until my webhook receives the event?
Thanks in advance for any answers or advice!
You can, but whether or not you should is primarily a business decision for you to make based on the customer experience you're hoping to achieve.
It will likely be influence by the exact integration path and payment method options that you're offering. If you're going to use the Payment Element with delayed notification payment methods, then you may want to wait for confirmation that the payment was successful.
https://stripe.com/docs/payments/payment-methods#payment-notification
But if you're using the Card Element(s) and only accepting cards, then part of the response from confirmCardPayment is the Payment Intent if the payment was successful so you have a more immediate indicator of success.
https://stripe.com/docs/js/payment_intents/confirm_card_payment
In my app, on the client side, I'm calling Stripe's "confirmCardPayment()" to finish the purchase. When the result comes back I take the result, if successful, and then call my server controller to finish the processing (DB entry).
QUESTION - Would it be possible to confirm the payment on the client side with Stripe and then receive the Stripe Webhook on the server side before I have time to post back to the controller to finish the payment processing? Or put another way, is the Webhook sent immediately or does it wait for some time before it's sent to the endpoint?
Stripe does not guarantee delivery of events in the order in which they are generated. You can read about it in more detail here : https://stripe.com/docs/webhooks/best-practices#event-ordering
You would want to always rely on the webhook to update your database or execute business logic as relying on requests triggered from the browser isn't reliable. E.g. Your customer could close the browser after the payment is authorised but before you are able to post to your server to update your database.
In the stripe documentation, it says:
So in this case, the checkout page goes to the success or failed page on my frontend.
I use the backend to track the payment status so that we can monitor the transactions in the admin portal, and the above approach seems dangerous to me.
When checkout is successful, it redirects the window to the success url. This means I have to call the backend API in the success page to update the payment status. However, the stripe is the source of truth about the payment status, and the status update on DB should come from Stripe, not come from a frontend page. At the very minimum, if a user refreshes the success page, it would have called the API again and again which is bad. Also, it is about "a user says I paid successfully" v.s. "Stripe says they paid successfully".
I tried the Stripe webhooks, but in the webhook data object, there is no information that I can use to link it to the sessionId that is generated from creating the checkout session, but the session id is the only tracking id I can get from Stripe about a payment.
What's the best practice, if Checkout is the only solution, to securely update my database?
You have 2 options:
Rely on webhooks. The checkout.session.completed event will describe a Checkout Session which contains its ID, which you hopefully saved when you created the Session earlier so you can link the two together.
Retrieve the session ID from the success URL once the payment is complete and retrieve the Session on your server, then check the Session's payment_status. This way your server can verify if the payment was actually completed or if someone just managed to guess the URL of your success page.
Stripe doesn't recommend only doing option 2, as it's very possible that users close the browser tab or window before the redirect to your success page can happen, resulting in a possible loss of payment confirmation. You should always use webhooks instead to guarantee your purchase fulfillment logic correctly fires.
You can get Stripe Payment status or session Details by session_id on asp.net core || .Net 5
var service = new SessionService();
Session session = service.Get(yourSessionId);
// You can track :-
session.Id;
session.PaymentStatus; // Paid or Unpaid
session.Status;
session.Mode;
//And more
I am using Stripe and I need to understand how to only process webhooks that are generated by Stripe behind the scenes. When my server sends something to Stripe (new subscription, new individual charge) Stripe will generate events that are sent via the webhooks I provide. Well, I don't need to process those since it will create a mess. I only want to process Stripe generated webhooks in situations like: failed charge at subscription renewal, manual modifications via the Stripe dashboard, refunds generated in the dashboard, etc).
I went through the events generated and I cannot find anything that would make a difference from those my API calls generate or those generated behind the scenes.
Is there something I am missing?
Update
- API call: event has a request id
- Stripe behind the scenes: event has null request_id
- Stripe dashboard: event has a request id (This still remains a problem)
If I discard all webhook events that are not null I will also discard Stripe dashboard events. I need to process Stripe behind the scenes and also Stripe dashboard generated events.
First of all, Stripe currently does not support identifying the incoming webhook event type. Looking in the Dashboard I indeed can see what initiated the event (API, Dashboard or Automatic) but Stripe's people said they don't support it.
However, there is a workaround. For anyone struggling with this I will describe what I did. An automatic Stripe generated event is easy to differentiate. It contains a null request field. Any other type of event will have a request id (ex: re_123h2kj18321hjk3218). The problem remains with differentiating between API and Stripe Dashboard generated requests. Therefore, the solution is to capture the request id for every request generated by the API. Whenever a webhook arrives to your server, you check for the request field NOT to be in the Storage System (DB, etc) OR that the request is null. This means that the event was generated by either the Dashboard or Automatically by Stripe (subscription renewal).
Steps:
Hook into the CurlClient provided by Stripe. Extend that class and
override the request() method. The request method returns the
response generated by Stripe servers. Capture the headers of the
response which would contain a Request-id. Store that in your
Storage (in my case a DB)
In your configuration files you need to specify that Stripe should use your own CurlClient. ApiRequestor::setHttpClient(new CurlClient()); (I've named my CurlClient too but you can name it whatever)
When a webhook arrives, you have three options to identify the type:
Automatic: if the event has a request=null
Dashboard: the request is not null and the request is not in you Storage
API: you're left with one situation. The request is not null but exists in your DB
As you can see, there's quite a lot of work for something really easy. All Stripe needs to do is provide another field in their webhook event name something like request-type with three options (api, automatic, dashboard). They already have this build but they don't allow it to be shown in the webhook event.
On the event object documentation, you'll see the request property documented. This property is set whenever the event came from an API request. Otherwise, if it's null it means there was no API request associated with it and it was what we call an Automatic event in the dashboard.
You need to discard any event where request is not null on your end!
I have a web service that creates Docusign envelopes with a PDF that needs to be signed. On my test environment, after the envelope gets created I query for the envelope status, as well as the recipient status. When using the API call, the respondents with bad email addresses have the status "autoresponded".
Now on my Docusign Connect implementation, I have two separate routes that get hit. One for when the email gets successfully sent or if the request is completed, and another one specifically for email delivery failures. When I had a single route, none of the recipients were marked as "autoresponded" like the API call returned (the API call result ends up being returned before the Connect implementation gets hit by Docusign).
After splitting them apart, I expected the email delivery failure-specific route to have the correct signature status. Unfortunately when this route gets hit, all recipients have the status of "Sent", regardless if their email is valid or not.
I'd contacted Docusign a while ago and their response was the number of events a single Connect implementation was listening for. By that assumption, this delivery failure-specific route should be getting a status of "autoresponded" like our API call is receiving, which doesn't seem to be happening. How can I get the Connect implementation to return the correct recipient statuses?
Every time I've opened a support ticket on their website, the corresponding account can no longer log in, meaning it's always a one-way communication to their support team. Has anyone gotten around this issue before?
My thought is that if the email failure route gets hit, flag that account as having a bad email address for one of the recipients and force the user to log into their accounts to see the actual status. Another option would be to query the API for that envelope's status, however I feel like a lot of delivery failures could easily trigger the max number of API calls.
Posting an answer, the original poster figured it out in the comment, but here is the answer for everyone else per Ricky Story:
"Return Recipient Auto Responded Status in Connect/API" that DocuSign Support should be able to enable.
To do that you would need to contact the DocuSign Customer Support and request them to enable this option.