Payout & Redemptions

How payouts and redemptions work.


From claim to payout

A payout begins when your backend submits a cashback claim to Fruga. At that point, Fruga records the entitlement and reserves the cashback amount in the user’s wallet. The user’s balance in the widget updates immediately — they can see what they have earned even before the money has moved.

What happens next depends on how your integration is configured. Fruga supports two payout models, and the right one for your platform is agreed during onboarding.


Payout models

Fruga pays the user directly

In this model, Fruga handles the end-to-end payment to your user’s bank account. When a claim is submitted, Fruga initiates a bank transfer directly to the user. If the user has not yet added their bank details in the widget, they will be prompted to do so — the payout is held until they complete that step. Once bank details are on file, payouts proceed automatically with no further action required from your side or the user’s.

This model minimises operational overhead for you. You submit the claim; Fruga handles everything else including payment processing, confirmation, and failure handling.

Fruga pays the partner

In this model, Fruga settles the cashback amount with you as the partner — either periodically in batch or via automated transfer, depending on your arrangement. You are then responsible for passing the funds to your end user through your own platform.

This model gives you more control over the payment experience and may suit platforms that already have an established way of paying users, or where regulatory considerations make it preferable to keep the payment relationship in-house. The widget reflects the cashback status accurately in both cases — it simply does not prompt the user for bank details, since that interaction happens on your side.

💡
Your payout model is set at the partner level during onboarding. Users do not choose or see which model is in use — the widget experience adapts automatically based on your configuration.

Payout status

Every cashback entitlement moves through a lifecycle that is reflected in real time inside the widget. Users can always see the current state of their earnings — whether a payout is pending, in progress, or complete.

The key states a user may see are: a payout awaiting their bank details (in the direct-to-user model), a payout in progress, and a completed payout. If a payout fails for any reason — for example, invalid bank details — the widget surfaces this clearly and prompts the user to take action.


Redemption context

Every cashback payout is tagged with a redemption context — a meaningful label that describes the event that earned it. This context is displayed prominently in the widget so users always understand exactly why they received cashback, building trust in the reward and reinforcing the value of the actions they take on your platform.

Rather than showing users a generic “cashback received” entry, the widget surfaces context-specific messaging — a user who purchased a new policy sees that reflected clearly in their earnings history, as does one who paid a claim excess. This level of transparency is a meaningful differentiator compared to opaque loyalty programmes where users often have no idea what triggered a reward.

ContextWhat it representsExample user-facing message
NEW_POLICYUser purchased a new insurance policy through your platform”Cashback earned on your new policy”
POLICY_ADDONUser added a supplementary product or add-on to an existing policy”Cashback earned on your policy add-on”
CLAIM_EXCESSUser paid a claim excess and is receiving cashback on that amount”Cashback on your claim excess payment”
OTHERAny qualifying event that does not fit the above — accompanied by a custom description you provideDisplays your custom description

The OTHER context is particularly flexible — it allows you to reward users for events specific to your platform that may not fit a standard category, without waiting for a new context type to be added. You provide a short description when submitting the claim, and that description is surfaced to the user in the widget.

For implementation details on how to set the redemption context when submitting a claim, see the Cashback Claim guide.