Developer guide · Stamp cards
Stamp-card workflows inside a complete Laravel application.
The stamp-card module ships with partner, staff, and member workflows. It is part of the application rather than a drop-in package.
- Form
- Application module
- Roles
- Partner, staff, member
- Records
- Progress and transaction history
Short answer
Start with the operating model.
The stamp-card module is part of the complete Reward Loyalty Laravel application. It includes partner configuration, program presentation, member progress, staff awarding and reward processing, transaction history, analytics, corrections, and QR entry. Use it as a maintained workflow or extend the source with the same attention to ledgers, permissions, and multi-business scope.
See how that module fits inside the complete Laravel loyalty application architecture.
Decision criteria
What the decision changes.
These choices affect configuration, staff work, economics, support, and the customer promise.
Program rule
Define what earns a stamp, the target, reward, availability, and completion behavior before changing code.
Counter event
Trace staff authorization, member identity, program scope, award, completion, correction, and activity records.
Extension fit
Use the existing module when the product workflow fits. Build custom logic only for a requirement the documented model cannot express.
Module map
Follow one stamp from setup to reward.
The user interface and ledger should agree across every role.
-
1
Partner creates the program
The card carries its club, content, stamp target, reward, availability, and design.
-
2
Member collects the card
The wallet shows progress and the business behind the program.
-
3
Staff adds progress
The counter flow resolves the member and program before writing the stamp event.
-
4
Staff processes completion
The completed card produces the configured reward workflow and records redemption.
-
5
Operator reviews history
Analytics and exportable transaction history support investigation and program review.
Extension work
Protect the ledger and role boundary.
A visual change is different from a new qualification engine.
Safe presentation work
Card layouts, business content, translated copy, and surrounding promotion can stay outside earning logic.
Integration work
Use the Agent API or another supported route when an external system should trigger the existing stamp action.
Domain changes
Custom thresholds, schedules, product matching, or cross-business behavior need new rules, tests, and migration care.
Product and operating limits
Keep the recommendation inside the product boundary.
- This is not a standalone Composer stamp-card package.
- Staff or an integration still needs a trustworthy qualifying event. The module does not infer a purchase from an unrelated payment system.
- Do not change ledger rows by hand. Use supported corrections or implement an audited offsetting action.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.