Write the offer as a rule customers can check

A promotion code is a customer-facing instruction to apply a particular discount under particular conditions. It is not a promise that every basket will qualify. Before a Hong Kong online shop distributes a code, it should write one plain-language rule containing eligible products, minimum spend, currency, customer eligibility, start and end time, redemption limits, and whether it combines with other offers. Stripe distinguishes the customer-facing promotion code from the coupon that defines the discount. That model is useful even when the shop uses another payment provider: marketing wording, checkout calculation and support policy must describe the same rule.

Do not publish “20% off everything” if the system actually excludes a category or applies a cap. Decide whether a threshold is measured before or after other discounts, and whether delivery fees count, then configure and test that exact basis. In a multi-currency shop, a single displayed number is ambiguous unless it names the currency; Stripe documents currency-specific minimum amounts for promotion codes. State the basis in the terms customers see before they spend time building a basket. These choices determine eligibility and can change the payable total, so they need an owner who can approve the rule and a test case that proves it.

A code such as WELCOME may sound like an ordinary first-order offer, but provider definitions can be narrower or different from a shop’s intended meaning. Stripe’s first-time restriction can treat a customer who initiated a PaymentIntent, even without completing payment, as ineligible; a previous trial may matter too. If the campaign means “first completed purchase,” verify that the configured rule implements that meaning before sending the campaign. Avoid telling a rejected buyer that they have already purchased unless the shop has checked its own transaction history. Explain the applicable eligibility rule, not an invented reason.

Let the buyer see the effect before payment

Put the entry control where shoppers expect to check the payable amount, label it in both languages, and provide an explicit Apply action. A shopper should be able to enter a code without losing their cart or being redirected unexpectedly. When the code is accepted, show the discount as a separate line with the revised total and currency. Keep the original item prices visible enough to audit the arithmetic. If shipping is calculated later, say which portion of the total remains provisional. A code accepted at one stage should not silently vanish when the buyer signs in or selects delivery.

When a code fails, identify the actual reason if it is safe and known: expired, below the stated threshold, excluded product, already redeemed, or not available to this customer. W3C’s error-identification guidance says an automatically detected input error should identify the item and describe the problem in text. “Invalid” alone makes a shopper guess, and colour alone cannot explain the condition. Keep the entered code so it can be corrected. For restrictions that could reveal private account information, give a neutral explanation and a support route rather than exposing another customer’s status.

If a discount appears dynamically without moving focus, make the updated result available to assistive technology. W3C describes a status message as information about the result of an action that appears without a change of context; such messages need a programmatic way to be announced. Use a concise success message such as “Code applied; discount and total updated,” then leave the full calculation readable in normal page content. Do not announce every keystroke or force focus away from the code field. Check the experience with keyboard input and a screen reader in both site languages.

Recheck a worked basket at each change

Consider an illustrative campaign: HK$40 off eligible merchandise when the eligible merchandise subtotal is at least HK$300, with delivery excluded. A basket containing eligible items totalling HK$320 and HK$35 delivery qualifies; the displayed payable amount is HK$315 if no other charges or discounts exist. This is an example policy, not a live offer or observed shop result. If the shopper removes HK$50 of eligible merchandise, the merchandise subtotal falls to HK$270 and the code no longer qualifies. The checkout must remove the discount, explain why and present the new total before payment.

Now add an excluded accessory to the same basket. It may increase the order total, but should not push the eligible subtotal over the threshold if the campaign excludes that category. This catches a common implementation error: calculating qualification from the whole cart while applying the discount only to selected items. Test the reverse too: a buyer changes a variant to one that is excluded, or changes the billing currency. The interface and the server should recompute from the authoritative cart and current rule, rather than trusting a total or eligibility flag sent by the browser.

At the final payment step, the displayed amount should agree with the amount submitted to the payment provider. If the basket or code changes while a checkout session is open, refresh or replace the session according to the provider integration before taking payment. Do not charge a stale amount and reconcile the difference with a later apology. Record the applied code identity, rule version, discount amount, currency and order snapshot so support can explain the calculation later. These are design controls, not claims that a particular payment platform automatically performs every check.

Handle expiry, limits and combinations honestly

Stripe’s promotion code object includes active status, expiry, maximum redemptions, redemption count and restrictions. A shop using Stripe must configure the applicable fields and test the relevant redemption path; other providers may expose different controls. Publish an end time with a time zone when a campaign is time-limited, especially when Hong Kong customers may see overseas marketing. Decide whether a code redeemed just before the deadline remains valid through a payment attempt and test the provider’s actual behavior. Do not present a vague “last chance” message if the configured code has already stopped working.

Combination rules need explicit tests, not just a sentence in the campaign terms. Try a code with an automatic markdown, a member price, free delivery and a second code. For each pairing, decide which benefit wins, whether both apply, and what appears in the total. Avoid a checkout that accepts the second code but silently removes the first. If only one code is allowed, say so before the buyer tries and make replacement deliberate. The support team needs the same rule, because its manual adjustment should not create a different discount from the website.

When a campaign has a redemption cap, customer-facing wording should not imply guaranteed availability merely because the campaign end date is in the future. Capacity can be exhausted sooner. The team should know how quickly the provider reports a redemption and which event marks it as used. Test two customers attempting the final available use, and inspect the actual order outcomes rather than trusting a visual counter. If a code becomes unavailable between entry and payment, stop the stale checkout, explain the updated total and let the buyer choose whether to continue.

Run a small release checklist

Create test baskets that cross each boundary: just below and exactly at the threshold, an excluded item, another currency, a returning customer, an expired code and a used-up code. Check the code field, textual error, discount line and amount sent for payment. Repeat after sign-in, delivery selection and cart edits. Review the English and Traditional Chinese campaign copy against the configuration, including the time zone and what “new customer” means. This is a more meaningful test than entering one happy-path code and seeing a green tick.

The final go or pause decision is straightforward. If the shop cannot state the offer precisely, calculate it from its authoritative order data, show the revised payable amount before payment and explain common rejection cases, hold the campaign until those gaps are fixed. Once live, keep a versioned rule and a way to inspect disputed orders. A useful promotion earns trust when the buyer can understand exactly why it applies or does not apply and sees the same amount on the order record as at checkout.

Before you proceed

  • Does the published offer match the configured eligibility and currency?
  • Does every cart change recalculate the displayed and charged amount?
  • Can customers understand a rejection and keep control before payment?

Sources & further reading