Let Customers Choose the Price: What Should Your Website Checkout Allow?

If customers may choose what to pay, decide whether that means any permitted amount, a suggested amount they can change or a bounded range. Explain what the payment buys and whether it happens once. A free-entry price field is a commercial policy, not just another input box.

This guide concerns specifying a customer-chosen amount. It does not establish permission to collect donations, tax deductibility or payment-provider eligibility. Those questions require separate checks before using charitable or fundraising language.

Decide what the amount represents

A hypothetical workshop might offer one downloadable practice pack at a price chosen by the buyer. Is there a minimum? Is the suggested value merely a starting point? Does choosing a higher amount change what the buyer receives? Write the answer before designing the payment screen.

Keep different models separate. Choosing a purchase price is not buying a gift-card balance, applying a discount to a fixed price or making a recurring pledge. Calling all of them “flexible payment” conceals different obligations and implementation requirements.

The Stripe Checkout documentation gives a concrete customer-chosen pricing example. It documents an optional preset that the customer can update and optional minimum and maximum bounds. A suggested figure and an enforced minimum are therefore different decisions, not interchangeable labels.

Check the shape of the purchase

For the documented Stripe feature, no additional line items can be added and quantity must be one. Promotion codes and discounts are unsupported, as are recurring payments and optional items. These are limits of that feature, not universal restrictions on all payment systems.

If your brief requires several independently priced items, a coupon or a monthly contribution, do not approve a demonstration of this simpler flow as though it covered them. Ask for a supported alternative and a fresh scope decision. Adding extra wording around the same checkout does not remove a provider limitation.

Also settle the currency and how the payable amount is presented before commitment. If taxes or other charges affect the total, obtain appropriate advice and specify the actual display and calculation separately. Do not improvise a tax rule from the fact that the buyer entered a number.

Define low, missing and changed amounts

Decide what happens when the amount is blank, below the allowed minimum or above the maximum. Distinguish a genuine free offer from a paid checkout with a positive minimum; do not promise that a zero entry will be processed without confirming the chosen system supports the intended journey.

Show the amount the customer is actually confirming. If they change it, the final confirmation and the resulting record should agree. A client-side preview alone is not the authoritative payment result. The developer should demonstrate that an altered request cannot bypass the agreed bounds.

Specify the entitlement separately too. What evidence makes the pack available, and what happens after an interrupted or uncertain payment? A visit to a thank-you page should not be accepted as the only proof that payment succeeded. Reuse your established verified payment process rather than inventing a second one for this pricing option.

Accept the policy, not only a successful payment

Using the provider's test environment, demonstrate the suggested amount, an allowed change, both boundaries and an invalid submission. Inspect the final recorded amount and the agreed access outcome. Try any excluded combination so staff can see that it is unavailable rather than unexpectedly accepted.

Bring the offer and its exclusions to a website or app project discussion and include those cases in the acceptance criteria. The useful result is an understandable customer choice within a supported checkout, not a promise that letting buyers choose will increase income.