Card rewards

Send card reward allocations after your backend applies transaction and refund policy.

Use Slices as the issuance step after your card program determines a purchase is reward-eligible and calculates its token reward.

This is a partner-qualified event integration, not a direct card-processor adapter. The same API works whether your business system receives events from a processor, an issuing platform, or an internal transaction service.

Qualify before sending#

Your card system decides which transaction state permits issuance, how partial or repeated events map to one reward, which purchases are excluded, and how refunds or disputes affect rewards.

Choose that policy before launch. Do not send an allocation for every webhook delivery: repeated messages about one transaction should not become repeated rewards.

Slices does not interpret merchant data, card-network states, or fiat purchase amounts. It does not price the reward token or compute a cashback percentage.

Calculate and persist exact tokens#

If your program starts with a percentage of spending or a monetary reward value, convert that decision into an exact token quantity in your own backend. Persist the amount, price/calculation reference, destination wallet, and stable economic event ID before calling Slices.

const reward = await slices.rewards.issue({
  campaignId: approvedCampaignId,
  recipient: { walletAddress: cardholderWallet },
  amountBaseUnits: calculatedTokenReward,
  event: {
    id: eligiblePurchaseRewardId,
    type: "card_purchase.eligible",
  },
  idempotencyKey: `card:${eligiblePurchaseRewardId}`,
});

These variables are your trusted application records. calculatedTokenReward is a base-unit string, not a purchase amount or dollar value. Use an opaque internal reference without cardholder information.

Handle retries at the business boundary#

A processor message ID is useful only if it represents the actual unique allocation you intend. Several messages may concern the same business decision. Establish a stable reward-event identity in your own system and use it consistently.

On uncertain Slices responses, resend the persisted instruction with the same key. Never recalculate using a newer market price during retry.

Refunds and disputes#

Slices can cancel a reward only before the operator's approval. It cannot retract a sent or delivered transfer. A refund event should not be modeled as a negative reward; negative amounts are rejected and no debit API exists.

Use your own policy to delay issuance, cancel grants the operator has not yet approved, or account for later adjustments elsewhere. Do not promise users that Slices can automatically claw back a sent reward.

Display and reporting#

Keep purchase amounts, reward token quantities, and approval status distinct. Show the original exact reward amount with its asset identity and Slices status. A request accepted by Slices is not a settled token transfer.

Related: Token amounts, Cancel a reward, and Funding and budgets.