Is there a timeout for a customer to make their payment and can it be changed ?
Let me explain my situation :
I have to add the payment on a PHP booking platform.
To ensure that a time slot is not reserved several times, the platform blocks the reservation for 20 minutes when the user clicks on the reserve button. If he has not completed filling in his information after this time, he must start again or if he does not finish, the reservation is released.
I should be able to make sure that the payment is a maximum of 5 minutes long. In this way, I initiate the payment after maximum 15 minutes after the start of the reservation.
It’s the easiest way I’ve found to not touch up the whole code. Unfortunately, I can't find this option in the API.
Otherwise, if I block the reservation permanently before the payment process, I have no method to unblock it if the user does not complete the transaction by closing their browser.
When a Checkout Session is created it has a Payment Intent associated with it. You can cancel that Payment Intent when you release the reservation, which will prevent the customer from paying.
Update: You can now set expires_at when creating the Checkout Session:
The Epoch time in seconds at which the Checkout Session will expire. It can be anywhere from 30 minutes to 24 hours after Checkout Session creation. By default, this value is 24 hours from creation.
You can also now explicitly and immediately expire a Checkout Session using the dedicated "Expire a Session" API endpoint.
Related
I'm trying to use Stripe checkout in a first-come, first-served buying process. Multiple buyers may be trying to buy the same item at the same time, and only the one who completes the stripe checkout process first should get it. At the moment, the stripe checkout session duration requires me to 'book' the stock item and only release them back into stock once the session duration expires (even if they close the tab).
Is there a way to set up Stripe Checkout in a way that would detect whether the item has already been purchased by another buyer (e.g. the stock is no longer available), and for example show an error when the user tries to pay?
If not, any suggestions as to alternative ways of implementing this functionality while still using Stripe?
You can listen for checkout.session.completed events and add some event handler logic to retrieve the Session object while expanding the line_items:
https://stripe.com/docs/payments/checkout/fulfill-orders
https://stripe.com/docs/api/expanding_objects
This will allow you to inspect the price and product IDs for the completed Session. You could then have some logic to expire any other Checkout sessions so no other customers are able to go through the payment flow:
https://stripe.com/docs/payments/checkout/managing-limited-inventory
https://stripe.com/docs/api/checkout/sessions/expire
You can use the paymentIntent that allows you to confirm or reject the payment later. You can create the paymentIntent for all the customers are trying at the same time and next take the first one and confirm only this paymentIntent and reject the others
Read the Stripe documentation:
Stripe | PaymentIntent
Hi I want to create a payment plan expiry reminder using django
Current Solution
Create a management command
Run the management command as a cron job
Problems with the Current sollution
in windows cron job doesn't work
it will run at particular time for all the users
I don't want to run cron for every minute
But i want to notify the user when 50%,30%,20%,10% and 5% time is remaining.
What I'm looking for
I'm trying to do something that can be done using the expiry_date ('available in the membership model of user and plan ')
using which we can just look at the membership which are expiring and notify them only.
final and most important i don't want to run a cron job every minute , but want to achieve a functionality which lets the user even remind that you have just 10mins remaining ,5 mins remaining kind of notifications.
as the process is for learning I'm not looking for any paid API's
I can see the below point in docusign documentation https://developers.docusign.com/docs/esign-rest-api/esign101/rules-and-limits/
2. Apps are limited to one GET status request per unique envelope per 15 minutes. If you exceed this limit, the request will not fail, but it will be flagged as a violation of rate limits, which can cause your app to fail review to go-live. To avoid exceeding this limit, design your app to poll at 20-minute intervals rather than 15 or, rather than polling for envelope status, your integration can subscribe to Connect to get status updates for the envelope.
My requirement is to poll the documents for each user using API:
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes?count=10&from_date=2021-10-21T04:38:51.0930000Z&include=recipients&order_by=last_modified&order=asc&folder_types=normal,inbox,sentitems,draft&start_position=0
and there documents using API:
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes/<envelope_id>/documents
and I have multiple user connection with same account Id, hitting these two APIs.
will it be flagged as rate limit violation? I have tried these GET api again and again but I can't see this violation status on my client? how can get update of this if in case it happens on my prod instance?
What is the goal of this API call?
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes?count=10&
from_date=2021-10-21T04:38:51.0930000Z&include=recipients&
order_by=last_modified&order=asc&
folder_types=normal,inbox,sentitems,draft&start_position=0
Is it to monitor incoming envelopes? If so you can use Recipient Connect to receive webhook notifications.
Otherwise, for a given DocuSign user, you can make the API call once every 15 minutes or less often.
You cannot make the call more often than once per 15 minutes per associated user. If your app uses a "system user" such as finance#your-company.com then you cannot call it more than once per 15 minutes since the results would not change.
And what is the goal of this API call?
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/
envelopes/<envelope_id>/documents
The documents in an envelope are generally not going to change.
More often, apps want to know when an envelope has completed, and then download the docs.
Update
The polling limits are:
per user
results must be expected to change
This means that you cannot poll after an envelope reaches a terminal state. IE only poll if the envelope is in the sent or delivered states.
And it is still not clear to me why an envelope's documents will change.
If you want to provide the current version of the envelope's documents to your application's user, give them a button to download the documents. Don't poll for them.
Finally remember the limit of 1,000 API calls per hour per account for your application. Your application will NOT be approved for additional API calls per hour with this type of polling activity.
I'm updating a webapp to Stripes SCA ready flow with PaymentIntent.
So far I have working (on my local test server):
Generate Intent on frontend and pass secret to form
Use Elements to collect card into
Use handleCardPayment to create the charge
Now here's the part where I am unsure. The handleCardPayment responses all seem to indicate a succeeded event, but the documentation warns to not use this repsonse, but instead wait for the Webhook response and only then fulfill customer orders.
Step 5: Asynchronously fulfill the customer’s order
You can use the PaymentIntent returned by Stripe.js to provide
immediate feedback to your customers when the payment completes on the
client. However, your integration should not attempt to handle order
fulfillment on the client side because it is possible for customers to
leave the page after payment is complete but before the fulfillment
process initiates. Instead, you will need to handle asynchronous
events in order to be notified and drive fulfillment when the payment
succeeds. Documentation
So far so good, I've set up test webhooks and tunneling through ngrok I can actually receive the paymentIntent from the Stripe webhook.
Now, my question comes at this point, where the Stripe documentation ends. How should I deal with the UI from the point of the "Pay" button being pressed, and how do I in the frontend detect that the webhook has been triggered?
I am wondering if I should poll my own server, which in turn retrieves a database result that indicated if the webhook for this order has been received? Or what is a reasonable way to deal with this, technically and from an UX perspective?
Any pointers?
I just implemented this, and I decided to poll my own server for the update and ask the user to wait. The webhook marks our internal representation as "paid", so we don't need to poll Stripe. If the webhook doesn't come within 30 seconds, we tell the user that it's ok to leave the page, and we'll email them the result.
Technically, these webhooks can take up to 7 days to come in, so that's why Stripe doesn't want you to have the user wait. In reality, it almost always comes in within 5 seconds, and I would rather just have the user wait and see a final confirmation in the same session.
I am dealing with subscriptions where a user is subscribed to a plan and it has an expiration.
So basically each user store has an expiration field.
I want to be able to get notified when a user plan is expired as soon as it is actually expired.
Right now, I have a job that runs on all users once a day and check if anyone has expired but ideally I would like to get a server postback or some sort of event whenever a user is expired without running this each day.
Can you think of any third party service / database / other tool that deals with these sort of things ?
A lot of services, Stripe for example, notify you with a webhook whenever a user's subscription is renewed / expired. Are they just running a job repeatedly like I am ?
Hope I made myself clear enough, would appreciate help in how to focus my search in Google as well.
My current stack is Mongodb, Node.js, AWS
Thanks
We do not know for sure, how Stripe handles it.
There are two solutions coming to my mind. Let's start with the simple one:
Cronjob
As you mentioned, you already have a Cronjob solution, but you can instead make it run each hour, or each 10 minutes. Just ensure you optimize your query to the maximum, so that it is not super-heavy to run.
It is attractive, easy to implement, very few edge cases, but as you might have though can be a performance drag once you reach millions of clients.
Timers
Implementation varries, and you need to worry about the edge cases, but the concept:
On day start* (00:00) query for all clients who are set to expire today, save them into array (in-memory). Sort the array by time (preferably descending).
Create timer to execute on last array's element time.
Function: If Client X expires now, query database to ensure subscription was not extended. Notify if it wasn't.
Remove Client X from the tracked array. Repeat step 2.
On day start* - Also run it on script launch.