How to Build a Customer Loyalty and Rewards Platform

Smile.io charges up to $999 per month for a loyalty program. For most retailers under 100,000 members, that is the right answer. Configure it in a week and ship. But at 500,000 members, the per-transaction API calls add up. At a fuel station network with tier structures tied to fuel grades and partner merchants, Smile.io's rule builder cannot cover the logic. And for a fintech company embedding rewards inside a payment card, the data cannot flow through a third-party vendor.

According to Accenture, over $100 billion in loyalty rewards go unredeemed annually. The platforms that drive redemption do so through fast, in-app experiences and well-timed push notifications, two capabilities that require owning your own tech.

Building your own loyalty platform is a specific decision with a clear profile for who it makes sense for. This is what that build actually involves.

The core data model: a double-entry ledger

A loyalty platform is fundamentally a double-entry ledger for points. Every point earned creates a credit entry. Every point redeemed creates a debit entry. The member's current balance is the sum of all entries.

Never store a balance as a single mutable number. A members table with a points_balance integer field looks simple. It is a trap. Under concurrent transactions (a member earning points from two purchases made 200ms apart), a single balance field produces race conditions. One write wins and the other is lost. The member loses points they earned.

The correct model stores every transaction as an immutable ledger entry.

ledger_entries
  id            UUID primary key
  member_id     UUID references members
  type          ENUM ('earn', 'redeem', 'expire', 'adjustment')
  points        INTEGER  -- positive for credits, negative for debits
  reference_id  UUID     -- links to the purchase or redemption that triggered this
  created_at    TIMESTAMP

The member's balance is SELECT SUM(points) FROM ledger_entries WHERE member_id = ?. This is auditable, reversible (add an adjustment entry), and safe under concurrent writes. This is the same double-entry principle used in financial accounting. There is a reason banks have used it for centuries.

When debiting points (redemption), use PostgreSQL row-level locking: SELECT SUM(points) FROM ledger_entries WHERE member_id = ? FOR UPDATE. Lock the rows, calculate the current balance, verify there are enough points, insert the debit entry, then commit. This prevents overdrafts under concurrent redemption attempts.

Earning rules engine

The rules engine defines how members earn points. "1 point per dollar spent" is the starting point. Real programs require more.

Forrester Research found that brands with configurable, rules-based earning logic retain 2-3x more active members than those with flat-rate programs. The differentiation is not the points. It is the perceived personalization of when and how points are earned.

Category multipliers: 2x points on coffee, 5x on fuel purchases. Merchant-specific bonuses: earn double points at partner merchants this month. Tier-based multipliers: Gold members earn 1.5x on every purchase. Promotional periods: 3x points on all purchases this weekend only. Partner earning: earn points at a partner airline or hotel when you pay with the brand card.

The rules engine evaluates each transaction against the configured rule set and returns a points amount.

ruleEngine.evaluate(transaction) → points

Build rules as configurable objects stored in the database. Each rule has: rule type, conditions (category matches, merchant matches, date range, member tier), multiplier or flat bonus, priority order, and whether the rule stacks with others or stops at the first match.

At transaction time, the engine loads active rules for the account, evaluates them in priority order, and returns a total points value. Log which rules applied to each transaction. This audit trail matters when members dispute their points balance.

For most programs, a match-and-sum approach works: apply all matching rules and sum the points. For programs where only the highest-value rule should fire (preventing stacking), use match-and-first-win.

Tier system

Tiers are statuses earned by reaching thresholds. Bronze, Silver, Gold, Platinum. Thresholds are defined by annual spend or annual points earned. Tier upgrades fire automatically when a member crosses a threshold during any transaction.

Tier benefits are configuration: a multiplier override (Gold members earn 1.5x, applied by the rules engine), exclusive catalog offers (only visible to Gold and above), priority booking or service access, or free product rewards on tier-up.

Tier downgrade is the operationally complex part. If a member does not maintain the minimum qualifying spend in a rolling 12-month window, they drop a tier. Calculate downgrade eligibility as a nightly batch job: scan all members, calculate their qualifying spend in the past 12 months, compare to tier thresholds, and downgrade where required.

Store qualifying spend separately from redeemable points. Many programs distinguish between points earned for qualification (every dollar spent counts) and points available for redemption (only base points count, not bonus multipliers). This prevents members from gaming high-multiplier promotions to inflate tier status.

Send a tier downgrade warning 60 days before the calculation date. Give the member a chance to make additional purchases.

Redemption: the speed problem

Redemption at point-of-sale has a hard performance requirement. Customers are waiting at the counter. The code lookup and validation must complete in under 200ms.

The redemption flow: the member opens the loyalty app, taps "Redeem", selects a reward from the catalog, and receives a single-use code. The code has a 15-minute TTL and is stored in Redis with SET code:{uuid} reward_data EX 900. The cashier scans or enters the code. The POS terminal calls your API: POST /redeem/{code}. The API checks Redis for the code (under 5ms), locks the member's ledger rows, deducts points, marks the code as used, and returns the discount value. The POS applies the discount.

The rewards catalog supports multiple redemption types. Discount vouchers ($10 off with 1,000 points) are the most common. Free product vouchers (free coffee with 500 points) require coordination with the POS to recognize the specific product. Exclusive experiences (private dinner with 50,000 points) require manual fulfillment flows triggered by the redemption event.

For online redemption, generate a discount code in your ecommerce platform (Shopify, WooCommerce) via API. The loyalty platform calls the ecommerce API to create the discount code, then presents it to the member. Track redemption by monitoring the discount code usage event.

Mobile app and digital wallet

The member-facing loyalty app shows the points balance, tier status and progress to next tier, transaction history, reward catalog, and personalized offers.

Push notifications are the retention mechanism. Send a notification within 60 seconds of a points earn event (triggered by a webhook from the POS or payment processor). Send a 30-day expiry warning for points about to expire. Send exclusive offer notifications for tier-specific promotions.

Apple Wallet and Google Wallet passes are the zero-friction loyalty card. The member adds their loyalty card to their phone's built-in wallet. At POS, they present the pass barcode without opening your app. Generate passes using the Apple Wallet pass.json specification and the PassKit API. Google Wallet passes use the Google Pay API for Passes. Both require a signing certificate and a pass update endpoint so you can push balance updates to the pass without member action.

The POS scans the barcode on the pass. Your API looks up the member, logs the transaction, and triggers the earning workflow. The pass updates with the new balance in the background.

Expiration and liability management

Points that expire reduce the company's outstanding points liability. Finance teams care about this. Outstanding points at redemption value sit on the balance sheet as a liability. The expiry schedule is a financial input, not just a product feature.

Standard configuration: points expire 12 months after earning if there is no account activity. Activity (any purchase, any redemption) resets the expiry clock.

The expiry batch job runs nightly. It scans ledger entries for points that will expire within 30 days, generates a list of affected members, queues warning notifications, and on the actual expiry date creates a debit entry of type expire for each expired points block. The expiry entry links to the original earn entries it is retiring.

Report on expiry trends monthly. A high expiry rate means members are not redeeming, which suggests the reward catalog is not compelling enough. A low expiry rate means the program is working well as a retention tool.

B2B loyalty: distributor and wholesaler rebates

B2B rebate programs use the same ledger model at larger scale.

A consumer goods company runs a rebate program for its distributors: purchase $100,000 of product in Q1, earn a 2% cash rebate ($2,000) paid at quarter end. The ledger tracks purchase commitments and rebate balances. The "reward" is a cash payment, not a voucher.

The data model extension: add an accounts layer above members (a distributor company has multiple buyers), track purchase commitments per account per period, and calculate rebate amounts at period end. The payout triggers a Stripe transfer or an accounts-payable entry in the client's ERP.

Tier structure in B2B programs is defined by quarterly or annual spend brackets: Bronze ($0-$50K), Silver ($50K-$150K), Gold ($150K+). Tier benefits are percentage rebates, priority allocation during supply constraints, or dedicated account management.

Reporting is the critical output. Distributors need to see their current spend position versus tier thresholds, their projected rebate at quarter end, and historical rebate payments. Finance teams need total outstanding rebate liability and expected payout schedule.

Business analytics

The platform generates data that answers operational questions.

Repeat purchase rate: what percentage of members made a second purchase within 90 days of their first? Members in the loyalty program versus non-members. This is the headline ROI number.

Average transaction value by tier: Gold members typically spend 30 to 50% more per visit than Bronze members. Quantify this for the program's business case.

Redemption rate: what percentage of earned points actually get redeemed? Low redemption (under 20%) is a sign the catalog is weak or the redemption experience is too difficult. High redemption (over 60%) means the program is popular but the liability is growing fast.

RaftLabs has designed and built points ledgers, tier engines, and B2B rebate programs for retailers, fintechs, and food and beverage chains. The non-obvious insight from those builds: redemption rate is the proxy for program health, but the metric that actually moves it is push notification timing. Teams that notify within 60 seconds of an earn event see 3-4x higher same-session redemption than those who batch notifications daily.

Cohort retention curves: for members who joined in a given month, what percentage are still active (made a purchase) at 3 months, 6 months, 12 months?

Tech stack

Cost and timeline

Build vs. Smile.io: when custom wins

Smile.io ($49-$999/month), Yotpo Loyalty, and Antavo cover the majority of loyalty use cases. The configuration time is days, not months.

Build your own when the following are true.

You have 500,000 or more members and per-transaction API calls to a third-party platform add measurable latency to your checkout flow. At scale, an external API call on every purchase is a 100 to 300ms tax on your conversion rate.

Your earning rules are proprietary. Fuel-grade multipliers, bank partnership earning rates, or category structures specific to your business that the Smile.io rule builder cannot express. The moment you are building workarounds inside Smile.io's configuration, the build case becomes real.

Loyalty is embedded inside a payments product. If you are building a branded payment card or a fintech app where loyalty points earn on card transactions, the data needs to flow inside your system. Routing every transaction through Smile.io's API introduces a dependency that affects transaction authorization latency.

You are running B2B distributor rebates. Off-the-shelf loyalty tools are built for consumer programs. A rebate program with quarterly commitment periods, cash payouts, and multi-buyer accounts under a distributor entity needs custom ledger design.

For everyone else, configure Smile.io and ship in a week. Spend your engineering budget on the product decisions that differentiate you from competitors.

For more context on building rewards into fintech products, see how to build an app like CRED. For the build conversation, start with our SaaS development team or MVP development process.