In commerce module there should be dedicated feature/method for generating discount/coupon codes.

[jainarpit1910]

Clear and concise description of the problem

As a developer using faker, I want a dedicated method for generating discount or coupon codes so that I can easily generate realistic, configurable, and reusable coupon codes for testing e-commerce systems, promotions, and checkout flows.

Currently, Faker provides generic string helpers like faker.string.alphanumeric() which work technically, but they are not designed specifically for the real-world needs of commerce use cases, such as:

• Coupon code formats (e.g., SALE20, WELCOME-5)
• Length constraints
• Prefix/suffix handling
• Readable human-friendly codes
• Avoiding ambiguous characters (O, 0, I, l)

Easily generating batches of coupon codes

A dedicated API under a Commerce-related namespace (such as faker.commerce.couponCode()) would improve usability, clarity, and consistency for developers working with e-commerce data.

I am willing to submit a PR for this issue if the maintainers agree with the proposal and design.

Suggested solution

In module faker.commerce, we could provide a method like:

faker.commerce.couponCode(options?)

Example implementation design:

faker.commerce.couponCode({
  length: 10,
  prefix: 'SALE-',
  suffix: '-2025',
  readable: true,
  exclude: ['O', '0', 'I', '1']
});

Expected behavior:

• Generate human-readable coupon codes

• Allow configuration for:

  • length
  • prefix / suffix
  • allowed / disallowed characters
  • uppercase output
  • numeric-only / alpha-numeric modes, etc.

Alternative

Currently, Faker provides generic string helpers like faker.string.alphanumeric() which work technically, but they are not designed specifically for the real-world needs of commerce use cases.

Additional context

Coupon / discount code generation is a very common testing need for:

• Cart systems
• Checkout flows
• Marketing campaigns
• Referral programs
• QA automation
• Load testing

Most developers currently re-implement this logic manually using faker.string or custom helper functions, which leads to:

• Duplicate implementations across projects
• Inconsistent formatting
• Harder-to-maintain test data
• Less expressive test code

Providing a native faker API improves:

• Developer experience
• Code readability
• Standardization of fake commerce data
• Adoption in commerce simulation use cases

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes ( 👍 ) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest

[xDivisionByZerox]

Props on the very well crafted issue 👍

One requirement I'd see is potential locale support. I know from German companies, that they provide coupon codes in the German language. So instead of "CHRISTMAS-25" it would be "WEIHNACHTEN-25". With this in mind, this feature could take advantage of the locale data by providing static "prefixes" and combine them with "patters" in a separate locale entry. We are doing this already in multiple other functions. For example faker.food.dish which uses faker.definitions.food.dish_pattern under the hood:

faker/src/locales/en/food/dish_pattern.ts

Lines 1 to 17 in 1cf3991

	export default [
	'{{food.adjective}} {{food.ethnic_category}} stew',
	'{{food.adjective}} {{food.meat}} with {{food.vegetable}}',
	'{{food.ethnic_category}} {{food.ingredient}} soup',
	'{{food.fruit}} and {{food.fruit}} tart',
	'{{food.fruit}} pie',
	'{{food.fruit}}-glazed {{food.meat}} skewers',
	'{{food.fruit}}-infused {{food.meat}} roast',
	'{{food.ingredient}} and {{food.meat}} pie',
	'{{food.ingredient}}-infused {{food.meat}}',
	'{{food.meat}} steak',
	'{{food.meat}} with {{food.fruit}} sauce',
	'{{food.spice}}-crusted {{food.meat}}',
	'{{food.spice}}-rubbed {{food.meat}} salad',
	'{{food.vegetable}} salad',
	"{{person.first_name.generic}}'s special {{food.ingredient}}",
	];

The disadvantage would be that options you suggested in your implementation would probably be hard to match. What is you opinion on providing locale support here?

[matthewmayer]

Conceptually it seems good.

I would perhaps try to start with a simpler set of options that are less likely to conflict eg

faker.commerce.couponCode({ suffix: '-2025', exclude: ['O', '0', 'I', '1'] });

Is already ambiguous.

• I'd say "prefix" and "suffix " can be handled just as easily by concatenating to the generated string.

• Maybe "readable" should always be true (if you want a non-readable code other existing methods might be more suitable).

• Other similar methods allow a {max, min} for length.

[jainarpit1910]

@xDivisionByZerox Thanks for the detailed explanation, it’s very helpful and I completely understand the value of locale-based definitions in Faker.

However, I’d like to share a slightly different perspective regarding coupon codes specifically.

Unlike product names, food, or personal details, coupon codes are not primarily language-driven data. In practice, many international companies still use English or pseudo-English terms in coupon codes even across non-English markets (e.g. SALE20, OFF10, SAVE25), because coupon codes are more identifiers than natural language content.

Also, in real systems, coupon prefixes are often:

• business-defined
• person-defined
• marketing-controlled
• manually configured
• reused across locales
• random text

rather than derived from a language database.

Because of this, a strict locale-driven implementation may reduce flexibility and make it harder for developers to generate codes that match real-world usage patterns in test environments.

I believe coupon codes are closer in nature to:

• identifiers
• tokens
• formatted keys
  than to user-facing translated content.

So while locale support could certainly be a nice enhancement in the future, I think the core goal of this feature should be:

generating realistic, configurable coupon codes for commerce testing rather than modeling language translation.

A lightweight, locale-agnostic approach (with readable patterns and clear structure) may offer more practical value initially, and locale-specific patterns could be added incrementally later if there’s demand.

I’m happy to help explore both directions, but wanted to share this perspective in case the initial design could remain simpler and more flexible for real-world testing needs.

[jainarpit1910]

@matthewmayer

I agree that keeping the initial API simple makes sense. I’m happy to remove the prefix and suffix from the method and let end users handle formatting themselves:

'SALE-' + faker.commerce.couponCode() + '-2026'

I also agree that coupon codes should always be readable, and for non-readable values, existing string helpers can be used. Using { min, max } for length also aligns well with other Faker APIs, so I’ll follow that pattern.

A simplified API could be:

faker.commerce.couponCode({
  min: 6,
  max: 10,
  exclude: ['O', '0', 'I', '1']
});