Is Paytm's scratch card the same thing as gambling?

No. A scratch card is a marketing and retention mechanic layered onto an already-completed transaction, and it does not involve the user risking money to play. What it does share with gambling mechanics is the underlying reinforcement schedule, the variable ratio pattern that behavioral psychology has studied extensively in the context of slot machines, because that schedule produces highly persistent behavior regardless of what it is attached to.

Why does Paytm attach the reward to the payment screen instead of a separate rewards section?

Attaching the reward to the transaction itself means the mechanic never has to convince the user to open a new screen or take an extra action. The user was already completing a payment. The reward moment rides on top of an action that was going to happen regardless, which is a large part of why the mechanic can run at scale without adding friction to the core payment flow.

Why do some scratch cards not give a reward?

Paytm's own help documentation confirms that not every scratch card guarantees a reward, and offers a "better luck next time" outcome as a normal, disclosed part of the mechanic. This is intentional rather than a defect. A reward that pays out every time functions as a fixed ratio schedule, which produces predictable pauses in behavior. The variable, sometimes-empty outcome is what keeps the mechanic behaviorally effective.

Can a business build a similar mechanic without Paytm's engineering resources?

Yes. Gamification components including scratch cards, spin the wheel, and treasure chests are available as configurable, no-code mechanics in platforms like Digia Engage, where probability, per-user limits, and reward pools can be adjusted from a dashboard without a new app release for every change.

Does a reminder-based mechanic like Paytm's bill reminders use the same psychology as the scratch card?

No, and that is the point. Bill and recharge reminders run on a predictable, fixed schedule tied to a known due date, which is closer to a fixed interval reinforcement pattern than a variable one. The two mechanics coexist in the same app because they serve different jobs. The reminder builds trust and habit around a recurring obligation. The scratch card adds unpredictable interest to an already-necessary transaction.

Paytm Scratch Cards: The Psychology of the Reward Screen

TL;DR

Paytm's scratch card doesn't live in a separate game bolted onto the app. It fires on the UPI payment success screen itself, the exact moment a transaction completes, and Paytm's own offer terms confirm that more transfers earn more chances to win.
The mechanic runs on a variable ratio reinforcement schedule. B.F. Skinner identified this as the reward structure that produces the highest, most extinction-resistant response rate of anything he tested. It's the same pattern slot machines are built around.
Paytm's own support documentation admits a scratch card doesn't guarantee a reward, and users routinely file complaints when a card fails to credit. That uncertainty isn't a side effect. It's designed into the mechanic.
Paytm runs a second, structurally opposite retention lever alongside it: bill and recharge reminders on a fixed, predictable schedule. Two systems, opposite psychological routes, same job: pull the user back into the app.
Sourcing note: every mechanic described here reflects a currently documented, live capability drawn from Paytm's own help center and offer pages, not a discontinued or historical feature. This draft has not yet been verified against a fresh, dated hands-on test session.

A payment completes. The screen doesn't just confirm the transfer went through. It shifts into a card, face down, with an instruction to scratch it. Underneath is cashback, or points, or nothing at all. Tens of millions of Paytm users see some version of this screen every month, and most of them would call it a nice bonus.

It's not a bonus. It's a reinforcement schedule, one of the most studied mechanics in behavioral psychology.

The Screen Fires on the Transaction, Not Around It

Paytm describes the mechanic plainly enough in its own help documentation. A transaction eligible for an active offer earns a scratch card, credited to the app's Cashback & Offers section. The user taps the card, swipes to reveal a reward, and the reward gets credited per the offer's terms. It can take a few forms: direct cashback to the linked bank account, cashback points redeemable for vouchers, or a discount coupon for a specific brand.

Where the card appears matters more than what's under it. There's no separate rewards tab to remember to open. It surfaces right on the transaction success screen, the same screen that confirms the money moved. Users complete the transfer first, then scratch the card on that same success screen to claim the cashback. Reward moment, transaction moment: same screen. Every payment carries a small chance of becoming a mildly exciting event instead of a purely functional one.

Frequency compounds the effect at scale. Paytm's own offer terms state directly that users who complete more transfers get more chances to win a scratch card. That single sentence is the entire mechanism. Send money more often, odds of a payout tick up. The behavior the platform wants, repeat transactions, is the same behavior that increases the odds of a reward. Not a loyalty program layered on top of payments. Same action, described twice.

The Reinforcement Schedule Underneath It

B.F. Skinner's operant conditioning research identified four basic reward schedules, split along two dimensions: whether the reward depends on the number of responses (a ratio schedule) or on elapsed time (an interval schedule), and whether that number or time period is fixed or variable. A fixed ratio schedule delivers a reward after a set number of responses, like a coffee shop punch card that pays out on the tenth purchase. A fixed interval schedule delivers a reward after a set time period, like mail arriving once a day. Both are predictable, and predictability changes behavior in a specific way.

On a fixed ratio schedule, the subject learns the pattern and develops a post-reinforcement pause. They know when the next reward isn't coming and act accordingly. Take that predictability away (a variable ratio schedule) and the pause disappears entirely. There's no safe moment to stop, because the very next response might be the one that pays off. The subject responds at a high, steady rate with almost no pausing between actions. Slot machines are built on this. It produces the highest and most extinction-resistant responding of any pattern Skinner tested.

Paytm's scratch card is a variable ratio schedule attached to a financial transaction. The number of transfers required before a reward lands isn't fixed or disclosed, and the terms explicitly note that offer eligibility, limits, and outcomes can change without prior notice. Users can't calculate when the next win is coming. That's precisely the condition that keeps a slot machine player pulling the lever, and in this version, keeps a payments app user tapping pay.

Why This Works Differently in a Payments App Than in a Game

A gaming app has to build a reason for the player to open it. A payments app already has one. The user was going to pay the electricity bill or send money to a friend regardless of any reward mechanic. The scratch card's job is narrower than manufacturing a session. It makes an already-necessary action slightly more interesting than it would otherwise be, without adding a single extra tap to the flow the user came to complete.

That's a much easier design problem than gamifying a discretionary app. It's also why the mechanic can run silently in the background of hundreds of millions of transactions a month without feeling like a distraction. Paytm's average monthly transacting users reached 7.7 crore in Q4 FY26, up 50 lakh year over year, a base large enough that even a modest lift in transaction frequency per user compounds into a real business outcome, and the reward mechanic never needed its own screen, its own onboarding, or its own reason for the user to show up.

The Honest Gap: "Better Luck Next Time"

A variable ratio schedule only works because most responses don't pay off. Paytm's own documentation says so directly: not every scratch card guarantees a reward, and the app's copy for a non-winning outcome reads "Better Luck Next Time." That line isn't an apology. It's a designed outcome, as necessary to the mechanic as the win itself: a schedule that pays out every time is a fixed ratio schedule, and fixed ratio schedules produce exactly the pause that variable ratio schedules exist to avoid.

You can see the friction this creates in Paytm's own support content. The platform's troubleshooting page for missing scratch cards walks through offer eligibility limits, a 24 to 48 hour credit delay window, and a formal complaint process through 24x7 Help for transactions users believe were eligible but never received a card. A support flow this specific doesn't exist for a mechanic nobody's confused or frustrated by. Users who transact expecting a possible reward and get nothing, or aren't sure whether they were even eligible, generate real support volume.

None of this makes the mechanic dishonest. Paytm discloses the non-guarantee in its own help center rather than hiding it, and the terms are published rather than buried. But the mechanic has a real cost: in support tickets, and in the users who read "better luck next time" one too many times and stop paying attention to the card altogether. A variable reward system that never pays out enough to stay credible ends up extinguishing the exact behavior it was built to reinforce.

The Other Lever: Bill and Recharge Reminders Run on a Different Schedule

Scratch cards aren't the only retention mechanic Paytm runs, and the contrast is worth sitting with. Alongside the unpredictable reward, Paytm operates a reminder system built on the opposite principle: total predictability. The platform's Reminders feature delivers advance notifications for regular commitments such as tuition fees, rent, and household bills, intelligently identifying frequent payments and suggesting reminders so users don't miss due dates. For a specific bill, users can set a reminder to fire a chosen number of days before the due date, with an option to enable Auto-Pay for the same bill going forward.

Where the scratch card is a variable ratio schedule, the bill reminder is closer to a fixed interval schedule. The electricity bill is due on roughly the same date every month, and the reminder fires on a predictable, disclosed schedule around it. There's no uncertainty to manufacture here, and no reason to. The user's goal is reliability, not surprise. A reminder that arrived unpredictably would be worse at its job, not more engaging.

Two mechanics, two opposite psychological levers, running at once without contradiction.

Mechanic	Trigger	Predictability	Psychological driver	Job it does
Scratch card	Eligible UPI transaction	Deliberately unpredictable	Variable ratio reinforcement	Makes an already-necessary transaction slightly more interesting, encourages transaction frequency
Bill and recharge reminder	Approaching due date on a recurring bill	Fully predictable, user-configured	Fixed interval nudging	Builds trust and habit around recurring payments, reduces missed due dates

Before a growth team ships a variable-reward mechanic anywhere in their own product, a few honest questions are worth asking first. Is the action the reward attaches to something the user was already going to do, or does the reward exist to manufacture a session that wouldn't otherwise happen? Is the non-win outcome disclosed clearly enough that users understand a reward was never guaranteed? Is there a support and eligibility path ready for the volume of "why didn't I get anything" queries a variable schedule reliably generates? And does a separate, fully predictable mechanic exist elsewhere in the product for moments where trust matters more than novelty?

The Transferable Principle

Attach the reward to the primary action, not to a side quest. The strongest version of this mechanic doesn't ask the user to do anything beyond what they came to the app to do. A scratch card that required a separate check-in or a dedicated rewards visit would compete with the core flow instead of riding on top of it.

Design the non-win outcome as carefully as the win. A variable ratio schedule only stays credible if the loss outcome is clear, fast, and free of ambiguity about whether the user got cheated. Paytm's disclosed "not every card guarantees a reward" language and its published eligibility terms are what keep the non-win from reading as a broken promise instead of a normal, expected result.

Match the schedule type to the job, not to a generic idea of engagement. A fixed, predictable nudge and an unpredictable reward aren't two versions of the same tool. One builds trust around a recurring obligation. The other adds interest to an already-necessary action. Get the pairing backwards, a surprise reward on a compliance-critical reminder, or a rigid fixed schedule where users actually want anticipation, and you undermine the specific job each mechanic is suited to.

Treat the reward pool as a cost line, not a free growth hack. Every scratch card that pays out is a real cashback or voucher cost. A variable ratio schedule is efficient precisely because most responses go unrewarded, but the win rate still has to be budgeted, tracked, and tied to a measurable lift in the behavior it's meant to encourage, not left running indefinitely on the assumption that it's working.

Beyond the Brief: What a Product Team Needs to Actually Ship This

Probability and per-user limits belong in the same dashboard as the creative. A variable ratio mechanic is only as trustworthy as its published limits. Offer terms that cap the win rate, the number of eligible transactions, or the total reward pool need to be configurable and auditable by the team running the campaign, not buried in a static terms page nobody updates.

Support tooling has to ship alongside the mechanic, not after complaints start. The 24 to 48 hour credit delay window and the formal escalation path documented in Paytm's own help center exist because a variable reward mechanic reliably generates a specific category of confused or frustrated user. Building that support flow at launch, rather than retrofitting it once volume shows up, is part of shipping the mechanic honestly.

Reward mechanics in Digia Engage carry the same configurability principle. Scratch cards, spin the wheel, and treasure chest formats are available as gamification components inside Digia Engage, with probability, per-user limits, and coupon codes controlled from a single dashboard, so a growth team can adjust the exact odds and eligibility rules this kind of mechanic depends on without a new app release for every campaign tweak.

Frequency capping and expiry dates prevent the mechanic from decaying into noise. A scratch card offer that never changes teaches users to stop noticing it, the same scanning-and-filtering effect that makes any static promotional placement fade into the background over repeated exposure. Rotating the win rate, the reward pool, and the offer window on a cadence, and expiring cards that go unscratched, keeps the mechanic feeling live instead of turning into another ignored badge on the home screen.

Key Takeaways

The reward moment and the transaction moment are the same screen. Paytm's scratch card fires on the UPI payment success screen itself (not a separate rewards tab), and that placement is most of why the mechanic works at all.

Underneath it sits a variable ratio reinforcement schedule, the pattern behavioral psychology has linked to the highest and most persistent response rate of any schedule tested, and the same pattern slot machines run on.

Paytm doesn't hide the downside. Its own support documentation discloses that not every scratch card guarantees a reward, and there's a documented complaint and eligibility-verification process for the "why didn't I get anything" moment a variable schedule reliably produces.

Right alongside the unpredictable scratch card, Paytm runs bill and recharge reminders on a fully predictable, user-configured schedule, the opposite psychological lever, doing a different retention job.

Take this past "add a scratch card" and the real lesson is about fit: matching the reward schedule type, fixed or variable, to the specific psychological job a moment calls for, and giving the non-win outcome the same design attention as the win.

External

External Sources: All Claims Attributed

What is a Paytm Scratch Card? - Paytm Help Center
Scratch Card Not Received After Paytm Transaction - Paytm Help Center
Rs 1000 Cashback on UPI Payment - Paytm, offer terms page
New Paytm 'Reminders' Feature for Managing Expenses - Paytm Blog
How to Set Up Bill Payment Reminders on Paytm App - Paytm Help Center
Paytm FY 2026 Results: Full-Year Profitability with PAT at ₹552 Cr - Paytm Blog, Investor Relations, May 2026
Variable Reward Schedules: Why Slots Use Social Media Psychology - Prof. Boston, on Skinner's reinforcement schedule research
Reinforcement, Positive, Negative and Schedules - Cogn-IQ Encyclopedia, on the four reinforcement schedule types and the variable ratio effect

Want to run a reward mechanic like this without waiting on an engineering sprint for every probability or eligibility change? Digia Engage's gamification components, including scratch cards, spin the wheel, and treasure chests, let growth teams control probability, per-user limits, and coupon codes from one dashboard, live in under 100ms with no app release. Book a demo to see how it works.

Paytm's Scratch Card Runs on the Same Psychology as a Slot Machine