AVRA product
AVRA Rewards: Channel Incentives
The trade scratches a hidden code, scans it, and the cashback reaches their UPI.
01 /Overview
The person who chose your product gets paid for choosing it.
An electrician decides which coil goes into a wall. A mechanic decides which filter goes into a car. A krishi kendra owner decides which bottle a farmer carries home. Brands already spend crores rewarding those decisions, through distributor schemes that pay in aggregate, late, and to whoever shouts.
AVRA Rewards pays per unit, to the person holding it. A hidden code inside the pack — under the same scratch foil that protects the authenticity code, or as a second QR inside — is scanned or typed, and a cashback reaches a UPI account. The wallet, the campaign rules, the velocity limits, the PAN and TDS record and the payout orchestration are all ours. The money is not. It moves on your own Razorpay X or Cashfree account, under your own keys.
- cashback to the claimant's own account
- UPI
- TDS handled, PAN collected above the threshold
- 194R
- rupees of yours held by AVRA
- 0
- payout gateways supported
- 2
The money path
AVRA never holds your reward money
On AVRA's side: the claim (code verified, campaign matched, budget checked), the wallet (an append-only ledger, one balance per brand) and the rules (velocity caps, PAN, TDS, holds). AVRA instructs the brand's own payout account — Razorpay X or Cashfree — and only that account sends the cashback to the claimant's UPI. AVRA never holds the brand's reward money.
AVRA's side: instructs and records
Claim
Code verified, campaign matched, budget checked.Wallet
An append-only ledger, one balance per brand.Rules
Velocity caps, PAN, TDS and holds run before any money moves.
instructs
Your side: the only place money leaves from
Your payout account
sends the cashback
The claimant's UPI
AVRA tells your gateway what to send, records what happened, and holds anything that fails a rule.
02 /How it works
A claim has to earn its way through five checks.
- 1
The label carries a second factor.
A reward can only ride a label with something the claimant had to physically reach: a scratch code under foil, or a second QR inside the pack. A single openly printed code cannot carry one — it would be claimable off a shelf by anyone with a phone, and the platform refuses to attach a campaign to such a batch. - 2
The campaign says what this batch pays.
A campaign has a kind, a rate, a window and a budget, and it is attached to specific batches. A batch with no campaign shows no claim card at all — not a card that fails, no card. The budget is summed live from the claims and re-checked under a database lock, within the claim's own transaction, so a campaign cannot be overspent by two claims arriving together. You are emailed at 80% and at 100%. - 3
The claimant proves possession, then identity.
Where the reward is a second QR, it pays only if that same label's outside code was already verified on the same device. Then a phone number, an OTP, a consent tick, and — optionally, every field skippable — where they bought it, from which shop, at what price, and whether they are trade or a consumer. - 4
The rules run before the money moves, not after.
Rolling 24-hour caps on claims, payout value and spend. A breach does not reject the claim; it holds it, with a reason, for a human on your team to release or reject. A programme can set held claims to release on their own after a period you choose, or to wait for a person. Every hold reason is written in plain words for the claimant too. - 5
The payout leaves your gateway.
Straight to the claimant's UPI ID, which is checked when they save it. If the gateway refuses, the payout holds with the gateway's own reason attached and can be retried on a new UPI ID. Above the Section 194R threshold, PAN is required before the money moves, and the deduction is recorded.
The claim funnel
Four checks between a scan and a payout
A claim passes four checks in order: a second factor on the label, a live campaign in its window and budget, proof of possession, and the velocity caps, before it is paid. The first two failures show no claim card at all, the third tells the claimant to scan the outside code first, and a velocity breach holds the claim for a person to decide.
Scan
- 1
Second factor present?
If not: no claim card
- 2
Campaign live, in window, in budget?
If not: no claim card
- 3
Proof of possession?
If not: “scan the outside code first”
- 4
Velocity caps?
If not: held — a person decides
Paid
03 /What your team sees
Two groups of screens, and the one you will actually live in.
The rewards console splits into what you operate — overview, claims, members, purchases, warranties, redemptions, payouts, tickets — and what you set up — programme, campaigns, tiers, vouchers, settings. Most days the only screen that matters is Claims with the status filter on held, because that is where a human decision is waiting.
Two things on these screens exist because of how this money behaves. Every figure is in paise internally and shown in rupees, so an export reconciles against a bank statement. And redeemed points sit in the total row alone, because points are pooled across campaigns while cash is not.
04 /What the buyer sees
Scratch, type, done.
No app. The claim card is on the same page the camera opened. A phone number, a six-digit code over WhatsApp, a tick, and the amount is in a wallet they can see — with the payout's status and, if it is held, the reason in plain words rather than a spinner.
The wallet is per brand; the identity is not. One phone number is one AVRA identity across every brand on the platform, which is stated in the consent the claimant agrees to. An electrician who claims from three brands signs in once and sees three balances.
05 /Where it fails
What this does not do, and who can still cheat it.
Channel rewards is a programme that hands strangers money on the strength of a code. Everyone in this category sells fraud detection; almost nobody names the attack. Here are the ones that matter.
The shopkeeper with the carton open can claim.
Proof of possession stops the remote attack completely — a photographed inside QR forwarded to fifty phones pays nobody, because the reward only pays where the same device already verified that label's outside code. It does not stop somebody physically holding the carton, who can scan both. What works against him instead: the outside code's scan limit is spent, so the real buyer reads scanned before and you get a clone-attack alert; a burst from one device trips the velocity caps and holds the payouts; and the pincode, shop name and device on every claim make a counter that claims forty packs an hour visible in the data.
A campaign is only as safe as the batch it is attached to.
A single-code batch cannot carry one, and the platform refuses. If somebody insists on printing the reward code openly, the reward is claimable off the shelf and no rule can fix that.
Velocity rules hold; they do not judge.
Every cap is a hold with a reason, never a rejection. You choose, reason by reason, whether a held claim waits for a person on your team or is paid after a set time, once the caps are checked again. That is deliberate — an automatic rejection of a real electrician is worse than a queue — but budget and fraud holds wait for a person by default, so someone has to work that queue. Budget for that.
Per-claim payouts are expensive at small reward values.
A gateway charges roughly the same to send ten rupees as to send a thousand. Paying every ten-rupee claim individually can spend a large share of the reward pool on transfer fees. Use a minimum withdrawal or a weekly sweep. We will tell you this on the implementation call rather than after the first invoice.
Cashfree cannot be reconciled both ways.
Cashfree publishes no list-transfers API, so the nightly check that compares our record against the gateway's can only run one way for a Cashfree brand. This is said on the settings screen when you choose the gateway, on every mismatch alert, and in an audit row written on each run. Razorpay X reconciles both ways.
Rewards are adults only.
There is no age question anywhere, and there will not be one — asking a birth date is what would put us on notice that a claimant may be a child. The programme is adults-only by construction, and a UPI payout already requires the person's own bank account.
We do not run your scheme for you.
No field force, no dealer onboarding team, no scheme design. The platform runs the rules and the money; the programme is yours.
06 /Integration
The work is yours, and it is mostly paperwork.
Three things have to exist before a rupee moves, and none of them is code.
A payout account in your own name.
A WhatsApp sender.
A tax decision.
Effort on your engineering team: none. There is no API to integrate and no SDK to install. That is a limitation on other pages; here it is the answer.
07 /What it costs
The label, the programme, and the transfer — separately, because they behave separately.
- Per label
- One credit, the same as any label.
- The programme
- Quoted with your rate. It covers the rules, the wallet, the tax record and the support a rewards programme takes.
- Messages
- The OTP and the notices, at Meta's published India rate for WhatsApp, with no markup.
- Per payout transfer
- Your gateway's own fee, on your own account. Not marked up by AVRA.
- The reward itself
- Yours, from your account.
The last two lines are the ones to read twice. AVRA does not take a percentage of your reward pool and does not hold it. A platform that holds the float has an incentive you should not have to think about.
08 /Questions
Questions.
How fast does the money reach the electrician?
We will publish a measured median, not a marketing number. What we can state today: the claim is instant, the payout is queued immediately, and anything that trips a rule is held with a reason rather than silently delayed.
Who holds the reward money?
You do. Payouts run on your own Razorpay X or Cashfree account under your own credentials. AVRA instructs and records; it never holds a float, which also means there is no balance of yours to reconcile against ours.
What stops one person claiming hundreds of codes?
Four things in order: the code must have a second factor they physically reached; a second QR pays only where the same device already verified that label's outside code; rolling 24-hour caps on claims, payout value and spend, which hold rather than reject; and a ledger that makes a device claiming forty packs an hour visible. It does not stop a shopkeeper with the carton open — see Where it fails, which we would rather you read than not.
Do you handle TDS?
Yes. Under Section 194R, PAN is collected before a member's payouts pass ₹20,000 in a financial year, and the deduction is recorded. Statements and exports are in the console. We are not your tax advisor.
Can the same label carry both a reward and an authenticity check?
That is exactly what a rewards batch is. On a two-QR label the outside code answers authenticity with a scan limit of three, and the inside code carries the reward and pays only after the outside one was verified on the same device.
Can I run two offers at once — a Diwali rate and a normal rate?
Yes. Campaigns are separate objects with their own kind, rate, window and budget, attached to specific batches. A batch belongs to one campaign at a time, and moving a batch between campaigns happens in one transaction so it is never left without one.
What if a claim is fraudulent and I have already paid?
A paid claim can be voided by a platform admin and the ledger reverses it, but the money has left your gateway. That is why the rules hold before the payout rather than after it, and why a held queue that somebody actually works is part of running this programme.
Does the claimant need to be in my dealer network?
No. Anyone holding the pack with an Indian phone number and a UPI ID can claim, which is the point — the electrician is not on your dealer list. If you want it restricted, that is a campaign design question and worth a conversation.
Print one batch and scan it yourself.
The fastest way to judge this is a sheet of real labels and a phone.
Trust, made visible.
connect@avrascan.com · +91 91737 47583 · Navacara Infotech, Ahmedabad, Gujarat, India