A store-wide redemption system, plus role updates over the API
A redemption system configurable across the store, categories, and products, with product-specific values on shared methods and role updates over the API.
01 ·Redemption methods across the store, categories, and products
The rewards store replaces its single Custom Redemption Options block with Redemption Methods, an ordered list of ways a trader can redeem a reward that you configure at three levels: the store, a category, or an individual product. A category can follow the store's methods or set its own, and a product can follow its store, follow its category, or define custom methods of its own, so you set the common methods once and override only where a product needs something different. Each method carries a title, description, icon, and an enable toggle, collects the default fields you check (Name, Phone Number, Address) plus any custom fields you add (text, numerical, single-select, multi-select), and keeps its redemption conditions. Methods reorder by drag, and a method a product inherits shows as read-only. Every existing product's redemption options carry over into the new model with no change to what a trader sees at checkout.
Redemption is the spend half of the earn-and-spend reward loop. Configuring methods at the store or category level lets a broker with a large catalog keep reward fulfillment consistent across products while still tailoring an individual one.
02 ·Product-specific values on inherited methods
An inherited redemption method can now carry product-specific values. On a store or category method you declare Product Fields, and each product that follows the method fills in its own value for them. You reference a field as a token inside the method's title, description, or redemption condition, and at runtime the product's value takes its place, so one shared method reads with the right detail on every product that uses it. A category method titled with a price token, for instance, shows each product's own price. When a product is missing a value that one of its fields requires, it shows a warning in the product list and on the product itself, and the method is unavailable to the trader until the value is filled in.
This keeps one method definition serving many products, so a broker who fulfills rewards the same way across a catalog writes the method once and lets each product supply only the detail that differs, such as an amount or an account reference.
03 ·Update a trader's roles over the API
The API that updates a trader's record can now change their roles. A single call can add roles to a trader, remove roles, or replace their roles outright, alongside the other fields the endpoint already updates. A broker syncing membership from their own CRM or back office can keep a trader's portal roles in step with their system of record.
Roles decide what a trader can see and earn in the portal, so setting them straight from a CRM keeps the tier and access decisions made in one system reflected in the loyalty program.
Purchase History shows product images at a 16:9 ratio and lists a reward's currency value ahead of its icon.
12 Jul