01 / BACKGROUND
Background
Merchant certification depends on user identity, historical orders, company information, phone numbers, ID numbers, and external verification. Different roles have different eligibility rules: some may apply directly, while others must meet a single-order purchase threshold. The flow must also handle duplicate applications, refunded orders, cross-company phone relationships, ID uniqueness, and multiple API outcomes. When these rules are scattered across screens, discussions, and interface notes, user, admin, and API behavior can diverge. The project therefore focused on turning identity, order, uniqueness, and verification logic into one executable and testable rule system.
02 / MY ROLE
My Role
Mapped eligibility for sales users, partner influencers, senior influencers, bound users, clerks, and retail users, identifying which roles may apply directly and which require a single-order purchase threshold. Standardized order-counting rules so only successfully paid and not fully refunded orders qualify. Defined validation and uniqueness rules for name, ID number, phone number, and company information; specified which fields become read-only after submission and what admins may still edit; designed external verification inputs, matching order, five result types, unverified-record handling, and update actions; and added QA scenarios for duplicate submissions, partial matches, multiple matches, refunded orders, abnormal responses, and API failures.
03 / CORE PROBLEMS
Core Problems
Multiple base and additional identities may coexist, so eligibility priority must be explicit. Bound users and clerks require a purchase threshold, while sales users, partner influencers, and senior influencers do not. Phone numbers, ID numbers, and company information follow different uniqueness scopes. Order statistics must exclude fully refunded transactions and use a consistent rule for refund-in-progress states. External verification may return unmatched, partially matched, verified, or duplicate results, making a shared state matrix essential for consistent API and admin behavior.
04 / SOLUTION
Solution
Split the certification flow into six modules: eligibility, purchase threshold, form validation, duplicate prevention, admin processing, and external verification. The system first determines entry visibility from identity priority, then checks qualifying single-order purchases only for roles that require a threshold. Submission validates ID, phone, and company-phone uniqueness before creating a record. Key user-side fields are locked after submission, while admins retain only required edit permissions. External verification processes eligible unverified records and returns explicit states based on company-name and ID matching. Eligibility tables, validation tables, and a state matrix keep user, admin, API, and QA rules aligned.
05 / PROCESS & RULES
Process & Rules
01Identify the current user role and determine whether the certification entry is shown and whether a purchase threshold applies
02For roles requiring a threshold, validate a qualifying single paid order that has not been fully refunded
03Collect certification information including name, ID number, phone number, and company details
04Validate ID, phone, and company-phone uniqueness according to their respective scopes
05Check duplicate applications and conflicting data before creating a new certification record
06After submission, lock key user-side fields while preserving necessary admin edit permissions
07Admins review application records, certification states, and duplicate or abnormal data
08External systems verify eligible unverified records using company name and ID number
09Return one of five verification outcomes and update the matched record according to the defined rule
10Standardize how paid, refund-in-progress, and fully refunded orders affect eligibility calculations
11Use a state matrix to map each input and match result to a clear status and follow-up action
12Cover duplicate submissions, partial matches, multiple matches, refunded orders, and API exceptions
06 / RESULT & REVIEW
Results & Reflection
Delivered a complete certification flow from entry visibility and eligibility checks through submission, admin processing, and external verification. Multi-role rules, purchase thresholds, uniqueness constraints, and API outcomes were converted into explicit tables and state rules, giving development a consistent implementation basis and QA a clear way to cover identity combinations, order states, duplicate data, and verification outcomes. User, admin, and API behavior became more consistent and easier to trace.
ReflectionThe main challenge was not screen design, but the interaction between identity, order, uniqueness, and verification states. Long-form requirement text is not enough when many conditions combine. Separating business objects and building eligibility tables, validation tables, and state matrices makes the rules easier to implement and test. For cross-system APIs, the product definition must also specify what is queried, how records are matched, which record is updated, and what is returned on failure.