Skip to main content
Anjelika Tan
Back to selected systems

Commerce and platform systems

Making Store logic reusable without hiding historical errors

Shaped a voucher Store into a configurable redemption platform spanning eligibility, permissions, order states, refunds, SDK and API contracts, and operational investigation.

My role
Product contracts, scope, state behaviour, migration choices, supportability and QA follow-through
Scope
Store, redemption and integration product work
Team
Product, engineering, QA, UX, SDK, API and client support teams
Delivery
Production correction for historical and future status responses
Evidence type
Production outcome
Observed result
Correct historical status responses for nearly 3,000 Store purchases in production, followed by positive client feedback.

Case Study 02

How the work unfolded

This case is about the product contracts around a transaction: who can see an item, what information is required, whether a user is eligible, what state is written and how an operator investigates the result.

Problem

A simple voucher flow had become a shared foundation for different reward types, client systems and fulfilment models.

Decision

Separate reusable eligibility, redemption and status contracts from client-specific integration logic, then preserve both future and historical correctness.

Observed result

Production work made historical API responses return the intended statuses for nearly 3,000 purchases without manually rewriting every order.

Sanitized product artifact

Redemption lifecycle

A sanitized view of the Store contract from eligibility through historical status.

  1. 1EligibilityPermissions, account checks and diagnostic states
  2. 2PurchaseProduct fields, redemption method and order creation
  3. 3FulfilmentInternal or external delivery with bounded callback scope
  4. 4Status and historyFuture-write correction and historical read-time status

My contribution: I defined reusable product contracts, migration choices, failure states and QA checks.

Observed result or limit: Correct status responses for nearly 3,000 historical purchases reached production; callback runtime use was not verified.

Context

ReturningAI serves businesses that configure loyalty experiences for their own members. Store purchases can depend on platform currency, broker account state, client-owned identifiers, regional access, external fulfilment and support workflows. The product had to serve those differences without becoming a collection of one-off implementations.

What I owned

I owned product decisions across eligibility, redemption methods, product fields, permissions, status precedence, refunds, migration defaults, SDK and API behaviour, and operational visibility. Engineers owned the implementation architecture; QA and UX challenged the behaviour through delivery.

How the system evolved

Phase 1: A narrow redemption flow

The Store began with coin-funded voucher redemption. The early model was useful, but category-first access and a fixed claim path became limiting as more clients and reward types arrived.

What changed

  • Voucher products and platform currency
  • Category-led visibility and simple purchase history
  • A straightforward code fulfilment path

What I shaped

I worked from the first version and used that history to distinguish what could be extended from what needed a new product contract.

Evidence and limits

The strongest proof is the decision and production outcome, not a claim that every Store capability had broad adoption.

  • Multiple Store components and SDK callback fields reached production; the callback-field SDK release was version 1.5.0.
  • The historical status correction reached production and made API responses return the intended result for nearly 3,000 purchases.
  • Purchase-success callback types and staging work existed, but production client use and populated callback logs were not verified.
  • Revenue, conversion and broad Store adoption were not measured in the available evidence.

What this demonstrates

Technical product work is often the choice between a quick client patch and a contract the platform can keep supporting. This system required both: narrow scope where reuse was not justified, and deliberate platform capability where the same problem would recur.