Skip to content
LoyumiReward Gifting

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
CUSTOMER PROMISE

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
Validate with authenticated Sandbox recordsProduct contract · no sample member, balance, or reward data
SpecificA named reward, not generic money
PrivateNo public recipient directory
ConsentedBoth people make a verified choice
RecoverableUnclaimed value has a safe return path

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.

01 / SENDER

Give something meaningful

Choose a concrete benefit, see the exact cost and finality, and know that an unclaimed gift has an authoritative restoration outcome.

02 / RECIPIENT

Accept without uncertainty

See who sent the gift, what it is, when it expires, and what accepting means before any permanent movement occurs.

03 / MERCHANT

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.

REAL SANDBOX WORKSPACE

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
  1. 01
    Configure 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.

  2. 02
    Use 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.

  3. 03
    Prove 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.

  4. 04
    Keep 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.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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.

Customer

Two verified decisions

  • Sender approves one exact gift
  • Recipient independently accepts
  • Private claim never proves identity
  • No account-existence disclosure
Value

Reserve before delivery

  • Original point-lot provenance
  • Each offered catalog unit held once
  • Idempotent state transitions
  • Returned versus expired points shown
Risk

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
Operations

One explainable record

  • Participant-safe sender and recipient views
  • Lifecycle webhooks and request IDs
  • Immutable audit and confirmation evidence
  • Deterministic timeout recovery
BEFORE CLAIMSender may cancelPoints and inventory remain reserved
RECIPIENT ACCEPTSAtomic commitSender redemption + recipient fulfillment
AFTER CLAIMFinal by defaultOnly governed fraud or merchant cancellation paths

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.

01 · VALUE CLIENTInvite, quote, reserve, reconcile, and read

A server-only key with gift value authority. It cannot impersonate either customer.

02 · WIDGET CLIENTIssue one-use customer handoffs

A separate server-only key creates short sessions. It cannot reserve or move points.

03 · DELIVERY CLIENTQueue work and record provider outcomes

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.

04 · FULFILLMENT CLIENTRecord isolated use and cancellation evidence

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.

05 · HOSTED CEREMONYVerify, disclose, and decide

The sender and recipient each authorize at Loyumi; the recipient can later open a first-party sent-and-received wallet.

Response loss is a normal path.

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.

LOYUMI SDK · SERVER + HOSTED UIFull guide
// 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);
SERVER Encrypted checkpoints · purpose-bound credentials · durable invitationDELIVERY Merchant-authenticated URL only · no claim capability in contentLOYUMI FRAME One-use Widget code · JIT recipient handoff · closure-only gift sessionMERCHANT UI Status hints only · finality comes from the backend receipt

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.

LAUNCH PRODUCT

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 now
NEXT

Loyumi Circles

Small verified households gain a shared redemption view while every contribution, expiration, permission, and refund remains attributable.

Design after gift evidence
CONTROLLED MODULE

Loyumi Transfers

Optional same-program point movement with recipient acceptance, account seasoning, caps, risk holds, preserved expiry, and no status progression.

Enterprise and jurisdiction opt-in
NON-GOAL

Universal reward currency

No cash-out, external wallet, anonymous transfers, multi-hop routing, resale market, or freely transferable cross-merchant balance.

Intentionally not built

THE 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 possible
SENDERSource-program reward valueReserved and then burned
GOVERNED CORRIDORExact partner economicsOne direction · capped · settled
RECIPIENTDestination catalog outcomeNamed, claimable entitlement

MEASURE THE MOMENT

Success is claimed value and incremental behavior—not points moved.

CUSTOMER

Does the gift land?

  • Delivery and claim rate
  • Time to accept
  • Reward-use rate
  • Repeat gifting
COMMERCIAL

Does it create growth?

  • Recipient activation
  • Incremental visit or purchase
  • Sender retention lift
  • Margin after reward cost
TRUST

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.