Modernization leaders
You have one existing program whose balances, rules, exceptions, and return behavior must be mapped before replacement.
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.
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.
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.
You have one existing program whose balances, rules, exceptions, and return behavior must be mapped before replacement.
You want source totals, imported values, ledger movements, and resulting balances compared without mistaking that work for an audit or accounting opinion.
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.
You can assign owners for program policy, data, exceptions, security, operations, and the written pilot decision.
The status labels below separate shipped surfaces from merchant-owned integration work and roadmap evidence. They are not customer adoption claims.
No multi-region, active-active, or failover architecture claim is made.
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.
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.
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.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.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.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.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.
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.
Loyumi is the operating layer between a merchant’s customer promise and the systems that must honor it.
Shape programs, tiers, rewards, campaigns, limits, pending rules, and expiration.
Use an isolated Sandbox to test earning, retries, balances, returns, and customer explanations.
Trace customer value to business evidence and recover without rewriting history.
Keep production behind evidence, ownership, least privilege, reconciliation, and approval.
Measure participation, customer value, margin, and outstanding obligations with defined metrics.
No invented customers, transactions, results, connectors, or adoption claims are used in this guide.
Configure organizations, environments, programs, members, rewards, campaigns, controls, and readiness evidence.
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.
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.
Keep earning, redemption, pending value, returns, adjustments, and expiry connected to 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.
Your trusted systems must identify the customer and send real business facts. This guide does not promise a connector catalog.
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.
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.
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.
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.
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.
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.
Check a step only after its evidence sentence is true.
A clear handoff shortens integration without pretending the merchant setup completed technical proof.
The console is where your team records the plan. Keep production locked while you prove the full loop.
A pattern is a starting structure, not a promise of a particular result. Combine mechanics only when the customer story remains simple.
Never begin by deleting the old system. Preserve evidence, rehearse the move, explain every difference, and keep rollback possible.
Document programs, statuses, balances, tiers, rewards, consent, expiration, exclusions, adjustments, and unresolved cases.
Define how every source field and rule becomes a Loyumi record. Mark anything that cannot be translated automatically.
Import into Sandbox, reject malformed records, and repeat until the process is deterministic and explainable.
Compare member counts and control totals for available, pending, reserved, redeemed, expired, and adjusted value.
Record exceptions, customer communication, support scripts, cutover owner, rollback trigger, and finance sign-off.
Freeze the agreed source window, run the proven process, verify control totals, observe real outcomes, and preserve both audit trails.
A small unexplained balance exception is still an exception. Assign it, resolve it, or explicitly approve its treatment.
Retain source exports, mapping version, import results, rejected rows, reconciliation totals, approvals, and customer communication.
A migrated order, reward, or balance needs the same explainable reversal and support treatment as new activity.
Record the baseline before launch. Choose a time window, comparison method, channel scope, reward cost, and owner before interpreting movement.
Members who join ÷ eligible customersIs the promise understandable and worth the small effort to join?
Members with a qualifying action ÷ enrolled membersAre enrolled people finding a reason to participate?
Members returning in a defined windowIs the program associated with durable behavior, not only sign-up?
Members who can use a meaningful rewardIs progress achievable before interest disappears?
Value redeemed ÷ value made availableAre rewards relevant and usable without damaging margin?
Issued value not yet settled, expired, or reversedWhat obligation must finance monitor and reconcile?
Granular controls help expert teams move precisely. Safe defaults and required evidence keep less experienced teams from making an uncontrolled promise.
Economics, rewards, limits, pending, expiration, and customer wording approved.
Enrollment, consent, matching, duplicates, deletion, and support access tested.
Earn, retry, balance, full return, partial return, and ordering behavior proven.
Opening records imported with no unexplained control-total difference.
Liability treatment, settlement, expiry, adjustment, and reporting ownership approved.
Velocity, referral, redemption, adjustment, identity, and partner-exchange abuse controls tested.
Least-privilege production credentials, rotation, monitoring, and incident containment ready.
Alerts, runbooks, customer scripts, rollback, recovery, and named on-call owners ready.
A second authorized operator reviews the current evidence before activation.
The obstacle is not the idea. The work is making the customer quote, funding, settlement, limits, reversals, and support correct every time.
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.
Each merchant approves the relationship, eligible programs, markets, and customer terms.
Show the source amount, destination amount, ratio, expiry, and any limit before confirmation.
Hold source value and destination capacity so neither can be used twice during the exchange.
Write linked ledger movements with one exchange reference and an idempotent outcome.
Reconcile funded value, fees, exceptions, and merchant obligations on the agreed schedule.
Define cancellation, return, dispute, expiry, insolvency, and partner-exit behavior in advance.
Open only what you need. Every answer separates what can be done now from what still requires proof or a published capability.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Post the return against the original source reference. The system can calculate a bounded full or proportional clawback while keeping the original history visible.
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.
There is no universal answer. Choose a disclosed rule that fits customer expectations, local requirements, program economics, and your ability to communicate reminders fairly.
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.
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.
Use these meanings in requirements, reviews, support scripts, and launch evidence.
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.