LOYUMI GIFTS · PROGRAMMABLE REWARDS SHARING
A reward feels better when it can become someone's moment.
Let verified members send a dinner, upgrade, experience, or merchant-defined benefit—with exact approval, a private recipient claim, reserved value, atomic acceptance, and an authoritative restoration outcome when a gift is not accepted.
- Verified sender
- Recipient acceptance
- Delivery or restoration receipt
Sender-approved. Recipient-bound.
One merchant-defined outcome
- Recipient gets
- An approved catalog benefit
- Claim window
- Set by merchant policy
- Value state
- Reserved until acceptance
THE PRODUCT INSIGHT
Gift the outcome. Keep the currency boundary.
Customers asking to “transfer points” are often trying to help a partner reach a reward, prevent useful value from going to waste, or create a memorable moment. A claimable reward solves that job without creating an anonymous, resellable wallet.
Give something meaningful
Choose a concrete benefit, see the exact cost and finality, and know that an unclaimed gift has an authoritative restoration outcome.
Accept without uncertainty
See who sent the gift, what it is, when it expires, and what accepting means before any permanent movement occurs.
Turn generosity into growth
Activate an existing member, measure claim-to-use behavior, and fund only catalog outcomes the program has explicitly approved.
“A gift should create a customer moment—not a shadow currency.”
Loyumi gifting design principle
AUTHENTICATED SANDBOX VERIFICATION
Run the real workflow. Do not rehearse it in a browser mock.
This public page contains no pretend balance, delivery, acceptance, or fulfillment controls. Sign in to create and inspect persistent Sandbox records through the same governed runtime used by the product.
Verify gifting with your program, members, policies, and evidence.
Sandbox stays isolated from Production, but its records are durable. The merchant workspace and APIs expose the actual invitation, reservation, delivery-work, entitlement, receipt, and audit states.
Open authenticated Gift operations Sign-in required · persistent Sandbox data · no real customer value- 01Configure a real Sandbox policy
Create your program, enable a merchant catalog reward for gifting, and set the claim, validity, and rolling-limit controls that the runtime will enforce.
- 02Use persisted member and gift records
Create Sandbox members, run the authenticated invitation and approval flow, and inspect the resulting invitation, reservation, and delivery work in the merchant workspace.
- 03Prove terminal outcomes
Exercise acceptance, use, cancellation, decline, expiry, restoration, and governed recovery through the real APIs and hosted customer surfaces—not a page-local reducer.
- 04Keep the evidence
Verify request IDs, ledger entries, delivery outcomes, entitlements, receipts, webhooks, and audit history before any Production review.
THE GIFTING FRAMEWORK
Six governed steps from intention to fulfillment.
The customer sees a gift. Product, risk, finance, support, and engineering receive one constrained and auditable contract.
- 01
Choose a giftable outcome
The merchant decides which catalog rewards may be gifted and sets the recipient-readiness rules, claim window, expiration policy, rolling limits, and open-invitation cap.
A specific benefit—not an open balance - 02
Establish recipient readiness
When enrollment or verification is missing, the merchant may send a private pre-value onboarding notice. It contains no reward, point cost, balance, or claim promise, and nothing is reserved yet.
Invite first without disclosing value - 03
Price and approve exact terms
After fresh readiness checks pass, Loyumi snapshots the offered reward versions, point cost, deadlines, cancellation rights, and finality disclosure. A cooled provider-linked sender starts a new provider authorization and approves that exact promise; a merchant value credential cannot manufacture the approval.
The promise cannot change mid-gift - 04
Reserve points and offered inventory
Eligible sender point lots and the finite approved option set are held together. Nothing is permanently spent while the recipient is deciding; unselected options are released at acceptance.
No oversell and no double spend - 05
Deliver a private claim
The merchant sends a durable private invitation with no reward capability in its URL or message. After the intended recipient authenticates, Loyumi mints the short-lived, one-use handoff just in time.
Durable delivery without a bearer reward - 06
Choose, accept, use—or restore
The recipient reviews one option or chooses from the approved set. Acceptance commits sender redemption and the selected entitlement atomically; decline, cancellation, or pre-acceptance expiry releases eligible original lots and inventory.
A tracked entitlement—or a restoration receipt
ENTERPRISE CONTROLS
Generous by design. Conservative with authority.
The launch model keeps customer presence, merchant value movement, and identity mutation in separate authority zones while giving every gift a deterministic recovery path.
Two verified decisions
- Sender approves one exact gift
- Recipient independently accepts
- Private claim never proves identity
- No account-existence disclosure
Reserve before delivery
- Original point-lot provenance
- Each offered catalog unit held once
- Idempotent state transitions
- Returned versus expired points shown
Bounded sharing
- Same-program verified members at launch
- No cash, resale, or onward transfer
- Fresh readiness boundary and program caps
- Fraud-only governed reversal path
One explainable record
- Participant-safe sender and recipient views
- Lifecycle webhooks and request IDs
- Immutable audit and confirmation evidence
- Deterministic timeout recovery
BRING THE WHOLE OPERATING QUESTION
Planning a pilot—or pressure-testing the boundary?
Talk with Loyumi about the customer journey, integration, value model, identity, delivery, finance, risk, privacy, or launch evidence.
THE INTEGRATION KIT
Separate purpose-bound clients. One hosted customer surface. No reward secrets in your browser.
The typed framework creates a durable pre-value invitation, evaluates readiness, schedules provider-neutral delivery, prices immutable terms, and mints the recipient handoff only after an authenticated arrival. Your application owns its customer entrypoint and delivery provider. Loyumi does not send email or SMS and does not fulfill the merchant benefit; it owns value linearity, exact consent, the gift wallet, use evidence, and the authoritative receipt.
A server-only key with gift value authority. It cannot impersonate either customer.
A separate server-only key creates short sessions. It cannot reserve or move points.
A dedicated delivery credential can enqueue onboarding, gift-ready, reminder, and retry work for your delivery provider. It cannot send a message itself, read gift value, or move points.
Your merchant or fulfillment provider uses a purpose-bound server credential to close an issued entitlement. Loyumi does not provide the benefit, create a gift through this credential, or act as either customer.
The sender and recipient each authorize at Loyumi; the recipient can later open a first-party sent-and-received wallet.
Persist encrypted checkpoints and replay the same operation and handoff generation after response loss. Advance to a new short-lived handoff only after the prior code is used or expires; render finality from the authoritative receipt.
// Merchant backend: separate purpose-bound authorities
const gifts = new LoyumiRewardGiftExperienceFramework({
valueClient, widgetClient, deliveryClient, fulfillmentClient,
senderIdentity, recipientIdentity,
widget: { deploymentId, origin: merchantOrigin }
});
const dispatcher = new RewardGiftDeliveryDispatcher({
...deliveryRuntime, // store, adapters, content, readiness guard
outcomes: new LoyumiRewardGiftDeliveryOutcomeRecorder(deliveryClient)
});
// Durable pre-value invitation; no claim authority is created
const invited = await gifts.createInvitation({
operationId, programId, rewardIds,
personalization, delivery,
senderContext, recipientContext
}, {
onCheckpoint: saveEncrypted
});
await saveEncrypted(invited.checkpoint);
const readiness = await gifts.refreshReadiness(
invited.checkpoint,
readinessGeneration
);
if (readiness.readiness.nextAction !== "quote_and_approve") {
await gifts.scheduleAndEnqueueDelivery(
invited.checkpoint,
{ phase: "onboarding_notice", kind: "initial" },
"onboarding-1", dispatcher,
{ templateId: "gift-onboarding" }
);
return renderReadiness(readiness);
}
// Capability issuance always re-resolves the live authenticated sender
const sender = await requireAuthenticatedSender(request);
const approval = await gifts.prepareSenderApproval(
invited.checkpoint,
sender,
{ onCheckpoint: saveEncrypted }
);
// Browser: callback is a hint, never proof of approval
mountRewardGiftSenderFrame({
container,
handoff: approval.senderHandoff,
onApproved: intent => notifyBackend(intent.id)
});
// Backend reloads the checkpoint and independently revalidates intent
const reserve = gifts.createReservationCheckpoint(
storedApprovalCheckpoint,
intentId
);
await saveEncrypted(reserve);
const reserved = await gifts.reserveGift(reserve, {
onCheckpoint: saveEncrypted
});
// Delivery contains only the merchant's authenticated invite URL
const delivery = await gifts.scheduleAndEnqueueDelivery(
reserved.checkpoint,
{ phase: "gift_ready", kind: "initial", scheduledFor },
"gift-ready-1", dispatcher,
{ templateId: "gift-ready" }
);
// Worker sends and attests the provider outcome with delivery authority
const dispatched = await dispatcher.dispatch(delivery.queued.delivery.id);
if (dispatched.outcome !== "delivered") {
return renderDeliveryPending(dispatched.delivery);
}
// A later merchant arrival handler must authenticate the intended recipient
const recipient = await requireAuthenticatedRecipient(request);
if (recipient.externalCustomerId !==
reserved.checkpoint.recipientExternalCustomerId) {
throw new Error("Gift recipient does not match this session");
}
// Only now mint the 60-second recipient handoff just in time
const arrivalCheckpoint = gifts.createArrivalCheckpoint(
reserved.checkpoint,
delivery.scheduled.delivery.id
);
await saveEncrypted(arrivalCheckpoint);
const arrival = await gifts.prepareRecipientArrival(
arrivalCheckpoint,
recipient,
{ onCheckpoint: saveEncrypted }
);
mountRewardGiftRecipientFrame({
container,
handoff: arrival.recipientHandoff,
onDecisionCompleted: refreshFromBackend
});
// First-party wallet reveals no customer data to merchant JS
const wallet = await gifts.prepareWallet({
role: "recipient", operationId: "wallet-1",
programId, context: recipient
});
mountRewardGiftWalletFrame({ container: walletHost, handoff: wallet });
// In a later fulfillment handler, after acceptance and observed use:
const accepted = await gifts.getReceipt(reserved.rewardGift.id);
if (accepted.rewardGift.state !== "fulfilled" ||
accepted.rewardGift.entitlement?.state !== "available") {
return renderReceipt(accepted.rewardGift);
}
await gifts.recordEntitlementUse(reserved.rewardGift.id, {
sourceReference: useReference,
occurredAt: new Date().toISOString()
}, { idempotencyKey: useOperationId });
const receipt = await gifts.getReceipt(reserved.rewardGift.id);THE PRODUCT LADDER
Sharing can grow without becoming money.
Loyumi separates four products that are often collapsed into “transfer points.” Each deserves its own authority, economics, disclosure, and launch decision.
Loyumi Gifts
One verified member sends one merchant-approved reward—or a finite choice of approved outcomes—to an intended recipient who must become ready before value moves.
Build and pilot nowLoyumi Circles
Small verified households gain a shared redemption view while every contribution, expiration, permission, and refund remains attributable.
Design after gift evidenceLoyumi Transfers
Optional same-program point movement with recipient acceptance, account seasoning, caps, risk holds, preserved expiry, and no status progression.
Enterprise and jurisdiction opt-inUniversal reward currency
No cash-out, external wallet, anonymous transfers, multi-hop routing, resale market, or freely transferable cross-merchant balance.
Intentionally not builtTHE LOYUMI DIFFERENTIATOR · ROADMAP
One day, points at one brand can become a gift at another—without becoming currency.
A governed cross-merchant gift would let the sender burn source points and issue one fixed destination reward to a verified recipient. The corridor sets the economics; the recipient receives the outcome; nobody receives a universal balance.
See the exchange rails that make this possibleMEASURE THE MOMENT
Success is claimed value and incremental behavior—not points moved.
Does the gift land?
- Delivery and claim rate
- Time to accept
- Reward-use rate
- Repeat gifting
Does it create growth?
- Recipient activation
- Incremental visit or purchase
- Sender retention lift
- Margin after reward cost
Does it stay safe?
- Restoration success
- Fraud and reversal basis points
- Support contacts per 1,000 gifts
- Unclaimed and expired value
QUESTIONS ENTERPRISE TEAMS ASK
Make the boundary understandable before launch.
Is a gift the same as transferring points?
No. A gift converts a sender's points into one named, merchant-approved reward or a finite choice of approved outcomes. A raw transfer moves a generic point balance. Loyumi Gifts launches with the more bounded outcome model.
Does the claim link contain the reward?
No. The durable merchant invitation contains no claim capability. After the intended recipient authenticates, Loyumi creates a short-lived, one-use handoff outside the URL; the recipient must still verify and explicitly accept before value commits.
Can the sender cancel?
Yes, until the recipient accepts. Cancellation, decline, and claim expiry release the reservation and return eligible points to their original lots. The receipt separately reports points that expired under their original rules while held.
Can a recipient regift or sell it?
No. The first release issues a named, single-recipient entitlement with no cash value, resale, splitting, merging, or onward transfer.
Can someone who is not a member receive a gift?
A merchant may begin with a private onboarding notice when the intended recipient still needs to enroll or verify. That notice carries no reward, point cost, balance, or claim promise, and no value is reserved. Only after fresh readiness checks pass can the sender approve exact terms and the gift proceed.
What is the cross-merchant opportunity?
A future corridor can let a sender burn points at one merchant to issue a fixed gift at another. The recipient would receive the specific outcome—not freely transferable destination points. That remains separate from the same-customer Rewards Exchange contract.
Does technical readiness authorize Production?
No. Each merchant must approve its customer terms, eligible value, privacy model, fraud controls, accounting and tax treatment, jurisdiction coverage, support, notification, retention, and dispute process before enabling live gifts.
MAKE THE FIRST REWARD SHAREABLE
Start with one reward, one verified cohort, and one promise you can keep.
Model the policy, run every claim and restoration path in Sandbox, then launch only after customer, legal, accounting, risk, privacy, and support owners approve the operating contract.