Define what the limit actually counts
Stripe lets you limit the number of times a Payment Link can be paid for. The link automatically deactivates when that limit is reached. In this feature, Stripe considers a link paid for when a Checkout Session is complete; the API instructions identify checkout.session.completed as the corresponding event.[4]
Editorial recommendation: name the control ‘completed-session limit’ in your operations notes. Do not label it ‘settled orders’ or ‘remaining stock’ without a separate business calculation. The documented unit is a completed session, not the number of products in its basket, the number of website visitors, or a count of bank settlement confirmations. This distinction matters before choosing the limit, not just when an exception arrives.
Set the control on the intended link
In the Dashboard, create or edit the link and select Limit the number of payments. Through the API, pass restrictions[completed_sessions][limit] when creating or updating the Payment Link. Stripe's example sets that limit to 1, separately from the line-item quantity to 1.[4]
Editorial recommendation: record the Payment Link identifier, the intended completion limit, its product and quantity configuration, and the person responsible for closing the offer. Check those values together before distributing the URL. A one-completion offer and a one-item basket are different configuration choices; do not let a copied example silently choose your commercial terms. This guide supplies no API call to execute and reports no live configuration change.
Keep delayed confirmation in a separate queue
Stripe's post-payment guide says to listen for additional webhooks when bank debits or vouchers are enabled, because those payment methods can take 2–14 days to confirm. A completed-session notification therefore cannot be used as a universal substitute for the relevant payment-confirmation flow.[5]
Illustrative scenario, not an observed transaction: a merchant offers a single place through a link with limit 1. A buyer completes the session using an enabled delayed-confirmation method. The completion-based link control and the merchant's decision to provide the service are different questions. Editorial recommendation: keep the order marked awaiting payment confirmation until your method-specific checks allow fulfillment. Do not reopen the offer solely because no settled payment is visible yet; first investigate the existing buyer's payment and your obligations to that buyer.
Write a closure message that does not invent a payment result
Customers opening a deactivated link see a default message. You can customize that message in the Dashboard or through the inactive_message parameter on link creation or update.[4]
Editorial recommendation: use language such as ‘This offer is no longer accepting new checkouts; contact support about an existing order.’ Avoid ‘your payment failed’ because the closure message is shown to visitors and does not establish the outcome of their individual payment. Give support staff a way to find the existing order rather than encouraging every returning visitor to create another one.
The retrieved documents do not establish a rule here for refund-driven restoration of the limit or the treatment of every already-open session at deactivation. Do not promise either behavior from this guide. If reopening is commercially necessary, have an operator verify current link, session and payment states and the applicable provider documentation before making a new offer.
Use the right records, not a lagging chart
For links containing a recurring price, Stripe directs operators to Billing > Subscriptions to inspect payments for completed sessions; for other links, it directs them to Payments and analytics > Recent payments on the link details page.[4]
The post-payment guide says Payment Link analytics can be delayed by up to 18 hours, are unavailable in a sandbox, and do not support links with recurring prices. Its revenue metric is gross sales volume in the account's default currency, regardless of presentment currency, converted using the exchange rate on the payment date.[5]
Editorial recommendation: treat the chart as retrospective reporting, not the authority for reopening a limited offer. Keep separate columns for completed sessions, confirmed payments, fulfillment decisions and support exceptions. A count discrepancy should trigger record-level investigation, not an automatic change to the commercial limit.
Accept the workflow only after testing its boundaries
Proposed acceptance checks, not executed Stripe test results: verify the configured limit on the exact link distributed to buyers; complete an eligible test checkout; inspect the resulting session and closure behavior; then open the link as a new visitor and check that the inactive message makes sense. Check both the intended basket quantity and the completion counter rather than assuming they are interchangeable.
Include a delayed-confirmation method only where your account supports it and verify that the application's fulfillment decision waits for its relevant payment evidence. Exercise the recurring-price reporting route separately if used. Do not make sandbox analytics a release condition when Stripe documents that analytics are unavailable there.[5] Editorial recommendation: close the operational review only when support can explain whether the offer stopped accepting checkouts, whether a particular buyer's payment is confirmed, and whether that order has been fulfilled. Those are three answers, not one status badge.
Sources and dates
Official Stripe documentation in English. No publication or update date is stated; retrieved and checked on 2026-09-21. The retrieval date is not a source publication date. This is editorial research, not a PayIn feature claim, account eligibility check, or legal advice.
- [4] Customize checkout for Payment Links · Checked 2026-09-21; source date not stated.
- [5] After a payment link payment · Checked 2026-09-21; source date not stated.