Karishma Garg
Blogs

Redesigning Loyalty and Vouchers on a B2C Cart: What We Changed and Why

Loyalty programs reward people for coming back. You buy, you earn points. On a later order you turn those points into money off, or you use vouchers you already saved. Promo codes are a separate thing. They also lower the total, but they do not spend your points.


That only really matters on the cart and at checkout. There is a basket. There is a total. The shopper wants to know if their rewards actually applied.


If that step is messy, it does not feel like a small UI bug. It feels like the store is making savings harder on purpose.


For the business, that is the fear: you already pay for a loyalty platform and you already paid for a replatform. If members choke on the cart, you lose repeat revenue, unused wallet value sits on the books, and support gets "my points disappeared" tickets. The program looks broken exactly where it should pay off.


This post is part three of a headless B2C redesign (Magento to headless, Next.js + SAP OCC). I handled frontend and UX. The loyalty program itself ran on Yotpo Loyalty. We redid how it showed up on cart and checkout, not the engine behind it. Part one: homepage. Part two: checkout.

What Yotpo is (and what we owned)

Yotpo is a commerce marketing platform. Most people know it for reviews. It also runs loyalty: points on purchase, tiers, referrals, and rewards customers redeem later.


On a themed store, Yotpo often ships as an embedded widget. We did not use that on headless. Loyalty ran on Yotpo's APIs, reached through SAP OCC (the commerce backend). The Next.js storefront called OCC; OCC handled the Yotpo integration. We owned the UI and the flow, not the loyalty engine.


Points, tiers, wallet vouchers, and the four-discount cap still came from Yotpo plus client configuration. Our job was to make that stack usable: summary row, modal, slot counter, grouping, and auto-apply best savings, all hitting the same apply endpoints the old UI used, without dropping in Yotpo's off-the-shelf cart widget.

How discounts worked on this cart

Before the redesign, this is what shoppers were working with.


Think of it in three lines:

Points  →  redeem for a $-off voucher  →  voucher sits on the cart
Wallet  →  apply a voucher you already own  →  same
Promo   →  type a code  →  uses one "slot" on the cart

You can only have four discounts on the cart at once. Loyalty vouchers and promo codes both count. One promo code usually means three loyalty vouchers max, not four.


Three rules the UI had to spell out:

  • Redeeming points costs them right away when the voucher is created.
  • Remove a voucher before you pay: it goes back to the wallet. Points do not come back.
  • We did not get to change Yotpo's rules or add one-tap "use all my points."

What the old cart looked like

Loyalty sat in a grey box on the cart: points, a dropdown, a Redeem button, and a row of ticket-shaped cards for each wallet voucher.


Twelve $5 vouchers looked like twelve tickets. Big codes in the middle. Scroll sideways on mobile. The user wanted five dollars off, not a code management job.


Promo fields lived at the top of the page. Applied codes became more rows. The same discount could show up in three places.


Nothing obvious said "2 of 4 coupons used." People often hit the limit only after they clicked. Checkout asked them to manage codes again while typing an address.


That is what the brand was risking: members who earned rewards but could not spend them smoothly, carts abandoned at the discount step, and a headless launch that felt worse than Magento for the people you care about most.

What we changed

Same Yotpo rules. Same OCC APIs. The goal was to stop the leak: make redemption finishable, surface wallet value, and make the cap visible before anyone wastes a click.


The work broke down like this:

  1. One "Rewards & Vouchers" row in the order summary. Tap it to open a modal. Promo codes stay in their own field.
  2. Show the cap. "0 of 4 coupons used" on the summary, so the limit is visible before the error.
  3. Group duplicates. Twelve $5 vouchers become one card: "$5 off · 12 available · Apply 1."
  4. Applied state on the summary. Green chip with the dollar amount and remove, same idea as the rest of the site's color system.
  5. Same UI on cart and checkout. No second ticket strip on the shipping form.

The modal holds tiers, wallet, and redeem. The cart page keeps focus on line items. Loyalty is there when you open it, not stretched across the whole page.

Auto-apply best savings (the best addition)

Of everything we shipped, this was the highest-leverage UX win.


The client would not approve "redeem all my points for this order in one tap." Shoppers still pick tiers and spend points themselves. But most heavy users already had wallet vouchers sitting unused. The hard part was choosing: one $30 voucher or three $5s? Which combination fits the four-slot cap when a promo code is already on the cart?


Auto-apply best savings answers that in one tap. It only uses vouchers already in the wallet. It does not spend points or invent new rules. It calls the same Yotpo apply path through OCC as manual Apply, but picks the mix that saves the most money for this cart within open slots and the promo rules.


On the old cart, that meant scrolling a ticket strip and guessing. Here it is the first card in the modal: dashed gold border, one action. Same outcome you would get if you did the math yourself. Most shoppers will not do the math.


For the business, that is the gain: loyalty budget and wallet inventory actually show up on the order instead of dying in the UI. Fewer failed redemptions. Less "coupon error" rage. A headless cart that still feels like the member is being looked after.

The program did not get simpler. The shopper's job did. One place for loyalty, one place for promos, the cap visible, duplicates grouped. And for wallet inventory, one tap to land on the best savings the rules already allowed.


You keep Yotpo. You keep OCC. You do not have to accept a broken cart as the cost of going headless. You fix the layer customers touch.


If your cart or checkout still spreads rewards across dropdowns, ticket grids, and duplicate applied lists, or you are replatforming and need to know what to fix first, let's talk. Reach me on LinkedIn or at karishmagarg.dev@gmail.com. If you are not sure of scope yet, the storefront audit is a fixed-price way to prioritize leaks before a full redesign.