1. The starting quantity is not the purchase record
A public developer question describes selling credit packs with adjustable quantities, then reading a quantity of one from the Session creation response after the buyer selected more. This is concrete demand for distinguishing an initial basket from a completed purchase, not evidence of a current Stripe defect. [3]
Stripe documents a separate step: after payment completes, request the finalized Checkout Session line items and their quantities. Removed items are absent from that response. [1] Treat the creation response as configuration, not a live object that updates inside your application. For one-time hosted Checkout, the fulfillment input should be the server-retrieved final basket, not the original cart, browser parameters, or a quantity copied into order metadata.
2. Set a deliberate range before opening Checkout
Enable adjustable_quantity on each relevant line item. Stripe documents a default minimum of zero and maximum of 99; the maximum can be set as high as 999999. If the starting quantity exceeds 99, explicitly set a maximum at least as large as that starting quantity. Checkout prevents removal of the only remaining item. [1]
Recommended configuration review: choose the initial quantity, minimum and maximum together. For a product that must remain in the basket, use a positive minimum. For optional accessories, allow removal intentionally and make your fulfillment code accept their absence. Validate product identity and business limits on your server before creating the Session; the adjustable control should express your approved offer, not replace that approval.
3. Reserve the maximum, then reconcile the difference
Stripe explicitly instructs integrations with adjustable quantities to reserve inventory using adjustable_quantity. rather than the initial line-item quantity. [1] This is a merchant inventory responsibility, not a statement that Stripe maintains your stock ledger.
Illustrative design: a Session starts at two units and permits up to six. Reserve six, not two. If the final purchase is four, convert four reserved units to committed stock and release the remaining two once the order is eligible for fulfillment. Store reserved, purchased and released quantities separately so a repeated notification cannot release the same two units again.
Recommended safeguard: allocate reservations atomically across competing buyers before opening their Sessions. A maximum of six on each Session is not a shared inventory lock. If reserving six per buyer is commercially wasteful, lower the offered maximum rather than silently promising stock you have not protected.
4. Retrieve final items inside one fulfillment routine
Stripe’s fulfillment guide requires a server-side routine that accepts a Session ID, retrieves the Session with line_items expanded, checks payment_status, fulfills the items and records fulfillment. It must tolerate repeated and concurrent calls. Webhooks are required because customers may never visit the success page. [2]
Recommended sequence: verify the webhook signature, resolve the Session to your local order, retrieve its final items, then map each Price to your internal product and use that line’s returned quantity. The adjustable-quantity guide also demonstrates listing Session line items directly. [1] Do not reconstruct units by dividing the payment total by a catalog price. If the retrieved basket is incomplete or contains an unknown product, retain an exception instead of guessing.
For delayed methods, completion alone is not permission to ship: Stripe routes later success through checkout.session.. [2] Keep unpaid orders pending. As an application design, commit the final basket, reservation adjustment and fulfillment marker together, with durable downstream work to prevent duplicate deliveries.
5. Test quantity changes, not just successful payment
Proposed sandbox checks: increase two units to four, decrease six to one, remove an optional second item, and attempt to remove the last item. Compare the server-retrieved basket with the chosen quantities; do not inspect only the creation response. Replay the notification and verify that neither stock release nor credit allocation repeats. For credit packs, multiply the final purchased pack count by your own defined credits per pack.
Also exercise delayed success and a missing product mapping. Record the Session ID, final quantities, reservation movements and fulfillment decision without unnecessary customer data. These checks were not executed for this article. Public sources were checked on September 22, 2026; publication and update dates were not established. Regional eligibility is not established by these sources. This guide makes no PayIn capability claim and does not cover expiry timers, invoice exports or Payment Link completion limits.
Sources and dates
Official documentation supports technical behavior; community questions demonstrate qualitative demand only. Retrieved and checked on 2026-09-22. Retrieval is not publication. Unstated dates remain unknown. This is documentation research, not a live-account test, PayIn feature claim, or legal, tax or financial advice. Account eligibility and regional availability require separate confirmation.
- [1] Make line item quantities adjustable · Publication date not stated; update date not stated · Checked 2026-09-22.
- [2] Fulfill orders · Publication date not stated; update date not stated · Checked 2026-09-22.
- [3] Get the quantity a user bought · Publication date not stated; update date not stated · Checked 2026-09-22.