Skip to the guide
LoyumiLoyalty infrastructure
RECONCILE & LAUNCH · CONTROLLED DESIGN-PARTNER PILOT

Reconcile a loyalty program before you replace it.

A fixed-scope, 6–8 week Sandbox evaluation for merchants that need to map balances and rules, prove the return path, and make a written migration decision. “Launch” means a launch decision—not a live launch.

Current public proof

Implemented product contracts, test evidence, limitations, and assurance gaps are public. Named production references, independently verified volume benchmarks, contractual SLA history, native connector availability, and external certification are not claimed.

WHO THE PILOT IS FOR

For an existing program with a real replacement decision.

The strongest fit has member balances or reward obligations to preserve, a concrete renewal, migration, or reconciliation trigger, and program, Finance, operations, and technical owners who can make a stop, extend, or proceed decision.

01

Modernization leaders

You have one existing program whose balances, rules, exceptions, and return behavior must be mapped before replacement.

02

Finance and risk owners

You want source totals, imported values, ledger movements, and resulting balances compared without mistaking that work for an audit or accounting opinion.

03

Composable product teams

You can use the published API or integration starters and own any required commerce or identity adapter; Loyumi does not install a native connector in this pilot.

04

Multi-team operators

You can assign owners for program policy, data, exceptions, security, operations, and the written pilot decision.

WHAT AN ENTERPRISE CAN VERIFY

A purchase decision needs a product boundary, an operating model, and a path to proof.

The status labels below separate shipped surfaces from merchant-owned integration work and roadmap evidence. They are not customer adoption claims.

Published architecture

One controlled value path

  1. Merchant systemsOwn commerce facts, customer authentication, consent, and fulfillment.
  2. Loyumi APIs and consoleApply environment, credential, rule, and readiness controls through HTTPS JSON, selected GraphQL, or guided operations.
  3. Tenant-scoped ledgerRecord source-linked value movements and derive balances.
  4. Customer surfacesUse merchant UI, the isolated Web Widget, Beta SwiftUI/Android View kits, or the Beta AI-native semantic projection.
  5. Evidence and exitInspect audit trails and export migration-critical records.

No multi-region, active-active, or failover architecture claim is made.

Integration status

Published, merchant-owned, and not yet published

Available
Public API 1.13.0 and OpenAPI 3.1 contract; stable TypeScript SDK 2.3.0 and CLI 1.5.1 downloads; stable iOS and Android 1.1.0 source downloads; stable React 1.0.0; a synthetic Shopify and Klaviyo mapping-conformance pack with status configuration_required; and three reviewed Loyumi integration starters
Available Beta
Selected-lifecycle GraphQL, Web Widget v1, Widget Studio, Native UI Kit 1.0.0-beta.1 for SwiftUI and Android Views, and AI-native rewards surface 1.0
Merchant-owned
Provider credentials and review, Shopify HMAC verification, real delivery and reconciliation, commerce, identity, consent, the native-app customer-session gateway, customer confirmation UI, notification delivery, coupon delivery, external fulfillment, fraud enforcement, analytics, and movement of partner settlement funds
Not published
A native Shopify app, connected Klaviyo provider, hosted sync, public package-registry distribution, broad turnkey connector catalog, model-provider integration, a turnkey partner network, and native live-gateway or physical-device proof
Security roadmap

Controls now; independent assurance next

Implemented
Least-privilege credentials, separated environments, signed outcomes, origin-bound widget sessions, audit evidence, and production readiness controls
Evidence still required
Independent penetration test, restore exercise with measured RPO and RTO, failover exercise, uptime history, contractual SLA, and SOC 2 or comparable assurance
Inspect every Trust Center status →
Commercial model

A visible starting point—not a checkout price.

Reconcile & Launch starts at a nonbinding $15,000 for the fixed 6–8 week Sandbox evaluation described below. Final scope, schedule, price, responsibilities, support, assurance requirements, and portable-exit terms become commitments only in an accepted statement of work.

Commercial boundary: the starting price does not include Production activation or create a generally available SaaS plan. No public sales calendar or self-serve production contract is represented.

Public referencesNone claimed
Verified volume benchmarkNot published
Independent assuranceNot yet published
Current evaluation statusReconcile & Launch pilot
6–8 WEEK PILOT PLAN

A dated evaluation with evidence at every exit—not a “go live fast” promise.

These are planning targets for the fixed starting scope, not observed customer averages, an SLA, or guaranteed delivery dates. The target begins after the statement of work, synthetic test inputs, access, and named owners are ready; a scope change requires written agreement.

  1. Week 1
    Qualify and bound

    Choose one migration question, inventory one existing program, map systems and owners, and agree what Loyumi does not provide.

    Exit evidence: accepted scope, architecture map, acceptance cases, risk register, and stop criteria.
  2. Week 2
    Map the opening position

    Map up to 5,000 synthetic, nonfinancial opening-balance test records, program rules, source control totals, and expected exceptions.

    Exit evidence: versioned mapping, input totals, rejected-record treatment, and approved exception rules.
  3. Weeks 3–5
    Prove one Sandbox loop

    Configure one earn rule, one useful reward, and one reversal policy; exercise earn, identical retry, balance, return, pause, recovery, and export.

    Exit evidence: repeatable transcript, request IDs, reconciliation pack, failure results, and unresolved-gap owners.
  4. Weeks 6–8
    Make the written decision

    Review the evidence and the unverified Production, connector, security, legal, Finance, support, and scale requirements.

    Exit evidence: stop, extend, or proceed memo, named approvers, open gates, and next-scope recommendation.
PILOT ACCEPTANCE CONTRACT

Agree how the migration proof can fail before it begins.

No Production or customer result is implied. Record the synthetic input set, merchant-provided control totals, expected outcomes, exception thresholds, evidence owner, and stop criteria.

  • Input integrityAccepted, rejected, and duplicate record counts agree with the synthetic source set
  • Control totalsMerchant-provided opening totals, applied values, and resulting balances have no unexplained difference
  • Lifecycle correctnessIdentical retry, full or partial return, balance, and export match the agreed cases
  • Decision readinessExceptions, recovery evidence, open Production gates, owners, and stop criteria are explicit
LOYUMI RECONCILE & LAUNCH

Prove one migration decision before you replace anything.

The fixed starting scope is a 6–8 week, Sandbox-only design-partner evaluation using synthetic, nonfinancial test records. Its nonbinding starting price is $15,000, subject to an accepted statement of work. It is not a checkout price, Production entitlement, customer reference, audit, certification, capacity commitment, SLA, or outcome guarantee.

INCLUDED IN THE STARTING SCOPE
  • One merchant organization, one existing program, and one Sandbox environment
  • Up to 5,000 synthetic, nonfinancial opening-balance test records
  • One earn rule, one useful reward, and one return or reversal policy
  • One merchant-owned commerce and identity proof path through published APIs or an integration starter
  • Evidence review with program, Finance, operations, and technical owners
EXCLUDED FROM THE STARTING SCOPE
  • Production activation, live traffic, cutover, or production support commitments
  • Native Shopify, Klaviyo, POS, coupon, notification, or fulfillment connectors
  • Real or pseudonymized customer data without separately executed privacy and security terms
  • Historical transformation beyond the bounded opening-position rehearsal
  • Independent assurance, causal lift, revenue attribution, retention, capacity, or ROI guarantees
01 · ORIENT

One platform, five jobs.

Loyumi is the operating layer between a merchant’s customer promise and the systems that must honor it.

01

Design

Shape programs, tiers, rewards, campaigns, limits, pending rules, and expiration.

02

Prove

Use an isolated Sandbox to test earning, retries, balances, returns, and customer explanations.

03

Operate

Trace customer value to business evidence and recover without rewriting history.

04

Govern

Keep production behind evidence, ownership, least privilege, reconciliation, and approval.

05

Learn

Measure participation, customer value, margin, and outstanding obligations with defined metrics.

WHO THIS IS FOR

A shared language for the whole merchant team.

  • Program ownersPromise, rules, and customer experience
  • Growth teamsPatterns, campaigns, and learning
  • Finance & riskCost, liability, limits, and evidence
  • OperationsSupport, incidents, and recovery
  • Technical ownersIdentity, commerce, API, and observability
02 · KNOW THE BOUNDARY

Use what exists. Label what is still a preview.

No invented customers, transactions, results, connectors, or adoption claims are used in this guide.

Available

Guided merchant console

Configure organizations, environments, programs, members, rewards, campaigns, controls, and readiness evidence.

Available

Server-side HTTPS JSON API

Use the 121-operation API 1.13 contract across 106 paths for identity and enrollment, commerce and returns, governed value, Reward Gifts, program configuration, imports, privacy, portability 1.6, partner exchange, investigations, operations, audit evidence, bounded analytics, exact ledger-close evidence, and 40 lifecycle webhook types.

Available Beta

Selected-lifecycle GraphQL

Query members, transactions, bounded analytics, and ledger-close evidence, or run one earn, return, redemption, or governed-adjustment step per mutation. It uses the same scopes, tenant boundary, idempotency receipts, and value state machines; it does not claim parity with all 121 HTTPS JSON operations.

Available

Traceable loyalty ledger

Keep earning, redemption, pending value, returns, adjustments, and expiry connected to evidence.

Available

Ledger-close evidence

Generate one program-period roll-forward with exact decimal point totals, double-entry controls, policy-based liability micros, journal mapping, readiness lights, and a deterministic integrity hash.

Requires your integration

Commerce and identity

Your trusted systems must identify the customer and send real business facts. This guide does not promise a connector catalog.

Available Beta

Web Widget + Studio

Compose, secure, publish, version, pause, and embed balance, tier, reward catalog, and activity surfaces. Guest content is copy-paste; personalized value uses a short-lived backend session.

Stable source · 1.1.0

iOS + Android SDKs

Add typed member, explicit program enrollment and unenrollment, activity, catalog, quote, reserve, commit, release, and reverse flows to a native app. The SDK calls your authenticated backend gateway, derives identity from the customer session, and has no Loyumi API-key setting.

Available Beta

Native UI Kits

Render balance, tier progress, reward cards and catalog, activity, or a composed rewards home with SwiftUI or Android framework Views. Explicit states, theme tokens, accessible semantics, and callbacks are included; customer confirmation and value movement remain in your app and backend.

Available Beta

AI-native rewards surface

Project a published rewards experience as privacy-minimized, versioned semantic JSON. Merchant labels are marked as untrusted data, while eligible entitlement actions require the same origin-bound session, explicit customer confirmation, and stable idempotency key.

Available

Governed partner exchange

Use the published bilateral agreement, quote, reserve, commit, release, settle, and reverse lifecycle. Merchants remain responsible for funding, external settlement movement, customer terms, and support.

Package boundary: The TypeScript SDK 2.3.0 and CLI 1.5.1 are official stable downloads; iOS and Android remain official stable 1.1.0 source downloads; React remains stable 1.0.0. SDK 2.3.0 Shopify and Klaviyo helpers prove only deterministic synthetic mapping conformance with status configuration_required; they do not claim a native app, provider connectivity, hosted sync, or live delivery. Native UI Kit 1.0.0-beta.1, selected-lifecycle GraphQL, Web Widget v1, Widget Studio, and AI-native rewards surface 1.0 remain Beta. Public npm, Swift, CocoaPods, Maven, or other registry availability and service general availability are not claimed.

Customer-surface boundary: Loyumi hosts the isolated Web Widget v1 runtime and publishes native and AI-native building blocks, not a complete merchant account portal, finished native app, or model-provider integration. Your team keeps ownership of customer sign-in, confirmation, and experience policy. Native SDKs call your trusted merchant backend gateway; Native UI Kits only emit selection intent. AI actions reuse the exact-origin widget-session boundary and must stay inside a trusted adapter. No Loyumi API credential enters a customer device or model context, and no live gateway, physical-device validation, or production agent proof is claimed.

Finance, fraud, and analytics boundary: Loyumi separates the bounded operational summary from deterministic ledger-close evidence. The close report proves its own roll-forward, double-entry balance, policy snapshot, and payload hash; it does not claim independent audit approval, upstream commerce completeness, a contractual financial statement, revenue attribution, campaign lift, forecasting, fraud analysis, or a BI connector. Merchants own external signals, policy approval, investigations, reconciliation, and sign-off.

03 · START SMALL

Your 55-minute Sandbox plan.

When your program inputs and console access are ready, each check earns visible progress on this device. It is encouragement—not production evidence, certification, or cloud-synced state.

YOUR DEVICE-LOCAL PROGRESS0 of 55 guided minutes checked

Check a step only after its evidence sentence is true.

DEVELOPER HANDOFF

Give the technical owner decisions, not guesses.

A clear handoff shortens integration without pretending the merchant setup completed technical proof.

  • Program and environmentSandbox identifiers, approved rules, rewards, pending, and expiry
  • Customer identity and consentStable customer ID, enrollment state, matching, duplicates, deletion, and support access
  • Commerce evidenceOrder and return source references, amounts, channels, items, and event timing
  • Credential and reliability contractRequired Sandbox credential scope, idempotency keys, retry behavior, request IDs, signed outcomes, and alert owners
  • Proof casesFirst earn, identical retry, balance read, pending release, expiry, full return, and partial return
  • Integration surfaceChoose the full HTTPS JSON API or the selected GraphQL Beta deliberately; record any operation that still requires the full API
  • Customer surfaceChoose hosted Web, native SwiftUI/Android Views, or semantic AI-native JSON; assign customer confirmation and accessibility owners
  • Launch boundariesNo client-side or model-context secret, no unapproved connector assumption, exact widget origins, a tested fallback, and a signed-session plan for personalized value
Ready to turn decisions into a Sandbox program?

The console is where your team records the plan. Keep production locked while you prove the full loop.

Open merchant console →
04 · CHOOSE A SHAPE

Six patterns. Start with one.

A pattern is a starting structure, not a promise of a particular result. Combine mechanics only when the customer story remains simple.

01

Everyday value

Best for
Frequent, easy-to-understand purchases
Start with
A clear earn rule and a small set of useful rewards
Watch
Do not let a large-looking point number hide weak customer value.
02

Tier recognition

Best for
Customers whose relationship grows over time
Start with
Few tiers, visible qualification, and benefits that feel different
Watch
Avoid permanent status promises unless the economics can support them.
03

Milestone benefits

Best for
Journeys with meaningful progress moments
Start with
One observable milestone and one relevant benefit
Watch
Reward the behavior you actually value, not activity that is easy to game.
04

Choice benefits

Best for
Members who value different perks
Start with
A small, controlled choice set at a clear eligibility moment
Watch
Define inventory, substitution, and reversal behavior before launch.
05

Referral loop

Best for
Programs with a trusted recommendation moment
Start with
A qualified referral event and transparent value for each party
Watch
Hold value until qualification and monitor linked identities and abuse.
06

Partner exchange

Best for
Two merchants with a deliberate shared proposition
Start with
A bilateral agreement, quoted conversion, caps, settlement, and reversals
Watch
Both merchants must accept the same versioned agreement; Loyumi records settlement evidence but does not move external funds.
05 · MOVE WITHOUT LOSING TRUST

A migration is a financial and customer promise transfer.

Never begin by deleting the old system. Preserve evidence, rehearse the move, explain every difference, and keep rollback possible.

  1. 1
    Inventory

    Document programs, statuses, balances, tiers, rewards, consent, expiration, exclusions, adjustments, and unresolved cases.

  2. 2
    Map

    Define how every source field and rule becomes a Loyumi record. Mark anything that cannot be translated automatically.

  3. 3
    Rehearse

    Import into Sandbox, reject malformed records, and repeat until the process is deterministic and explainable.

  4. 4
    Reconcile

    Compare member counts and control totals for available, pending, reserved, redeemed, expired, and adjusted value.

  5. 5
    Approve

    Record exceptions, customer communication, support scripts, cutover owner, rollback trigger, and finance sign-off.

  6. 6
    Cut over

    Freeze the agreed source window, run the proven process, verify control totals, observe real outcomes, and preserve both audit trails.

STOP

Do not launch with unexplained differences.

A small unexplained balance exception is still an exception. Assign it, resolve it, or explicitly approve its treatment.

KEEP

Preserve the evidence.

Retain source exports, mapping version, import results, rejected rows, reconciliation totals, approvals, and customer communication.

PROVE

Test the return path.

A migrated order, reward, or balance needs the same explainable reversal and support treatment as new activity.

06 · MEASURE HONESTLY

Give every number a definition and a cost.

Record the baseline before launch. Choose a time window, comparison method, channel scope, reward cost, and owner before interpreting movement.

01

Enrollment rate

Members who join ÷ eligible customers

Is the promise understandable and worth the small effort to join?

02

Active member rate

Members with a qualifying action ÷ enrolled members

Are enrolled people finding a reason to participate?

03

Repeat purchase

Members returning in a defined window

Is the program associated with durable behavior, not only sign-up?

04

Reward reach

Members who can use a meaningful reward

Is progress achievable before interest disappears?

05

Redemption rate

Value redeemed ÷ value made available

Are rewards relevant and usable without damaging margin?

06

Outstanding value

Issued value not yet settled, expired, or reversed

What obligation must finance monitor and reconcile?

Four rules for a credible review
  1. 1Compare against a recorded baseline or relevant control.
  2. 2Separate member selection from program impact.
  3. 3Include reward, discount, operational, and partner cost.
  4. 4Reconcile customer-facing totals to the ledger and finance view.
07 · EARN PRODUCTION

Production is an approval, not a button color.

Granular controls help expert teams move precisely. Safe defaults and required evidence keep less experienced teams from making an uncontrolled promise.

1
Program

Economics, rewards, limits, pending, expiration, and customer wording approved.

REQUIRED
2
Identity

Enrollment, consent, matching, duplicates, deletion, and support access tested.

REQUIRED
3
Commerce

Earn, retry, balance, full return, partial return, and ordering behavior proven.

REQUIRED
4
Migration

Opening records imported with no unexplained control-total difference.

REQUIRED
5
Finance

Liability treatment, settlement, expiry, adjustment, and reporting ownership approved.

REQUIRED
6
Risk & fraud

Velocity, referral, redemption, adjustment, identity, and partner-exchange abuse controls tested.

REQUIRED
7
Security

Least-privilege production credentials, rotation, monitoring, and incident containment ready.

REQUIRED
8
Operations

Alerts, runbooks, customer scripts, rollback, recovery, and named on-call owners ready.

REQUIRED
9
Approval

A second authorized operator reviews the current evidence before activation.

REQUIRED
08 · PARTNER VALUE

Yes, two merchants can agree to exchange value.

The obstacle is not the idea. The work is making the customer quote, funding, settlement, limits, reversals, and support correct every time.

Current product truth

API 1.13 publishes a bilateral value exchange lifecycle—quote, reserve, commit, release, settle, and reverse—after both merchants accept the same versioned agreement and define customer consent. Loyumi records linked ledger movements, cap usage, and settlement evidence; it does not move external settlement funds or turn every merchant's points into a universal currency.

  1. 1Opt in

    Each merchant approves the relationship, eligible programs, markets, and customer terms.

  2. 2Quote

    Show the source amount, destination amount, ratio, expiry, and any limit before confirmation.

  3. 3Reserve

    Hold source value and destination capacity so neither can be used twice during the exchange.

  4. 4Commit

    Write linked ledger movements with one exchange reference and an idempotent outcome.

  5. 5Settle

    Reconcile funded value, fees, exceptions, and merchant obligations on the agreed schedule.

  6. 6Reverse

    Define cancellation, return, dispute, expiry, insolvency, and partner-exit behavior in advance.

The bilateral control sheet

Conversion ratio and roundingFunding and settlement currencyPer-member and program capsEligible balances and rewardsReservation and timeout rulesReturns and linked reversalsFraud monitoring and disputesCustomer disclosure and consentTax, accounting, and legal reviewPartner exit and value wind-down
09 · ASK PLAIN QUESTIONS

Frequently asked, honestly answered.

Open only what you need. Every answer separates what can be done now from what still requires proof or a published capability.

01Can we launch in less than an hour?

When your program inputs and console access are ready, you can create a clear Sandbox program plan and proof checklist in about 55 minutes. That is not a production launch. Production may take longer because identity, commerce, migration, reconciliation, security, and approvals must be proven.

02How is Loyumi priced?

Loyumi Reconcile & Launch has a nonbinding starting pilot price of $15,000 for the fixed 6–8 week Sandbox evaluation scope described in this guide. It is not a checkout price, guaranteed quote, Production entitlement, discount, or generally available SaaS list price. Final scope, schedule, price, responsibilities, support, assurance requirements, and terms must be accepted in a written statement of work before work begins.

03Does “Launch” mean a live loyalty launch?

No. In Reconcile & Launch, launch means making a reviewable stop, extend, or proceed decision. The starting pilot does not include Production activation, live customer traffic, cutover, a production SLA, or a promise that a Production launch will be approved.

04Can we review customer references or proven transaction volume?

No named production customer reference or independently verified production-volume benchmark is published today. Evaluate the implemented contract in Sandbox, agree your own traffic and failure scenarios, review the Trust Center, and require written acceptance evidence before a production decision.

05Do I need a developer?

Not to learn the model, choose a pattern, configure the program, or paste a guest reward catalog. A technical owner is normally needed to connect trusted commerce and identity systems, and to add personalized widget sessions on a generic website.

06Does Loyumi replace an existing program?

It is designed to support a governed replacement. Preserve the old system, map rules and identities, rehearse imports in Sandbox, reconcile totals, and keep a rollback plan until production evidence passes.

07Which connectors, APIs, SDKs, and customer surfaces are available?

The account-free developer site publishes Public API 1.13.0 with 121 operations across 106 paths, the stable TypeScript SDK 2.3.0 and CLI 1.5.1 downloads, stable iOS and Android 1.1.0 source downloads, and the stable React 1.0.0 download. SDK 2.3.0 adds a merchant-operated Shopify and Klaviyo mapping pack with eight deterministic synthetic contract vectors; its status remains configuration_required and it is not a native app, connected provider, hosted sync, live delivery, or migration claim. CLI 1.5.1 includes an opt-in command that pins the official Loyumi API, rejects redirects, and operates on the user's Sandbox with unmistakably synthetic data; this availability statement is not a claim that a live proof ran for the current site deployment. Three reviewed Loyumi integration starters cover commerce earn and return, recipient-bound Reward Gifts, and signed webhooks. GraphQL selected-lifecycle support, Web Widget v1 with Widget Studio, Native UI Kit 1.0.0-beta.1 for SwiftUI and Android Views, and the AI-native semantic rewards surface are Beta. Public package-registry availability, a live merchant-gateway or physical-device proof claim, and a broad turnkey connector catalog are not claimed.

08Does Loyumi replace our finance, fraud, and analytics tools?

No. Loyumi provides two different ledger views: bounded descriptive analytics for operators, and a program-period close report with exact point roll-forward, double-entry checks, policy valuation, and a SHA-256 evidence hash. The close report is system-generated evidence—not an independent audit, contractual financial statement, revenue attribution, campaign lift, forecasting, fraud analysis, or a BI connector. Your finance, risk, and analytics owners still review assumptions and sign off.

09Can customers use points at another merchant?

Yes, when both merchants deliberately accept the same versioned agreement covering the ratio, customer experience, funding, limits, settlement, reversals, and support model. API 1.13 publishes the governed quote, reserve, commit, release, settle, and reverse lifecycle. Loyumi records linked value movements and settlement evidence; it does not move external settlement funds or create a universal points currency.

10Can we use Widget Studio for our live storefront?

Yes. Widget Studio publishes a versioned Web Widget v1 deployment for approved exact website origins. A guest reward catalog is copy-paste. Customer balances, tiers, activity, eligibility, and native entitlement redemption use a single-use code created by your trusted backend; the signed token stays inside Loyumi's isolated frame. Coupon delivery and external fulfillment use a connector.

11What happens when an order is returned?

Post the return against the original source reference. The system can calculate a bounded full or proportional clawback while keeping the original history visible.

12Who approves production?

Your authorized organization owners and operators do. Loyumi should support evidence and separation of duties; it does not replace your finance, privacy, security, or legal accountability.

13Should points expire?

There is no universal answer. Choose a disclosed rule that fits customer expectations, local requirements, program economics, and your ability to communicate reminders fairly.

14How do we avoid fake success?

Record the baseline before launch, define each metric and window, compare relevant cohorts, include reward and operating cost, and reconcile the ledger. A dashboard number without a definition is not evidence.

15Can we pause a program during an incident?

Yes. Pause the affected earning, redemption, campaign, credential, or production path while preserving ledger records and audit evidence. Do not delete history to make an incident disappear.

10 · SPEAK THE SAME LANGUAGE

Small glossary, fewer misunderstandings.

Use these meanings in requirements, reviews, support scripts, and launch evidence.

Available balance
Value a member can use now under the active program rules.
Campaign
A bounded change to the normal program for an audience, behavior, or period.
Clawback
A controlled reversal of previously issued value, usually linked to a return.
Environment
An isolated Sandbox or production space with its own records and credentials.
Expiration
The rule that ends the usability of value after a disclosed condition or date.
Idempotency
Protection that makes repeated delivery of one business fact produce one outcome.
Ledger
The evidence trail of value issued, held, redeemed, reversed, adjusted, and expired.
Member
A customer identity enrolled in a program with consent and program state.
Pending value
Value recorded but not yet available, often while a return or qualification window remains open.
Program
The core customer promise: earning, tiers, rewards, limits, pending, and expiration rules.
Reconciliation
Comparing commerce facts, ledger movements, and finance controls until differences are explained.
Reservation
A temporary hold that prevents the same value or inventory from being used twice.
Sandbox
A safe environment for configuration and proof without making a production promise.
Settlement
The agreed financial process that makes merchants whole after partner value is used.
Source reference
The stable order, return, or business-event identifier shared between systems.
YOUR NEXT RIGHT-SIZED STEP

Qualify one migration question before either team commits.

Bring the current program, decision trigger, approximate record volume, available synthetic evidence, and known connector or assurance blockers. A fit review is not acceptance, a start date, or a commercial commitment.