Back to portfolio
Y
Yatin Khar
Growth Memomemo_01
↓ Download Memo

CRED Beneficial Friction Experiment

Reducing Payment Support Tickets Using Behavioral Psychology

AuthorYatin Khar
DateMay 2026
StatusGrowth Memo · Behavioral Product Design
CategoryGrowth / Retention / Cost Optimization

Executive Summary

CRED's sub-second payment clearing speed—a technical achievement—was creating a paradoxical trust deficit among high-value transaction users. Customers paying ₹25,000 or more were generating panic-driven support tickets at a rate costing ₹5.5L/month, despite 97.8% of payments completing successfully.

Problem:Payment-related Cx tickets costing ₹5.5L/month due to instant payment processing creating a trust deficit
Solution:Introduced a 2.5-second "processing" UI state for transactions ≥₹25K using the Labor Illusion principle
Result:22% reduction in panic-driven support tickets; zero impact on payment success rate
01 Business Problem & Opportunity

Context

CRED processes millions of high-ticket credit card bill payments monthly. The payment gateway clears transactions in under 0.5 seconds. However, the Cx analytics team flagged a counterintuitive pattern: the faster the transaction cleared, the higher the support ticket rate for high-value payments.

The Speed Paradox

When users make payments representing a significant share of their monthly finances—income tax instalments, large credit card bills, rent advances—the psychological stakes are materially higher than a routine ₹500 transaction. The near-instant success screen, rather than reassuring users, created uncertainty. The most common paraphrased Cx complaint: “It happened too fast—I'm not sure it went through.”

The system provided no visible evidence of effort—no proof that a ₹75,000 payment had been securely routed through the bank gateway. The cognitive load of high-stakes financial transactions demands visible system feedback. The UI provided none, and that gap converted directly into support volume.

Cost Breakdown (Estimated — benchmark-derived, not internal data)

MetricEstimated Value
Payment verification tickets per 10K high-value transactions~180 (est. — derived from RBI Digital Payments report (2024–25) payment dispute rates for transactions above ₹10K, scaled to CRED's ₹25K+ threshold; not CRED internal data)
Average handling cost per ticket (avg ~15 min handling time, incl. escalations)~₹180 (est. — based on BPO/fintech industry Cx handling cost benchmarks; Deloitte India CX Cost Report 2024)
Monthly operational burden (~170K high-value txns/month)~₹5.5L (est. — 170K txns × 1.8% dispute rate × ₹180/ticket)
High-value segment share of tickets vs. volume~64% of tickets from ~18% of volume (est. — consistent with Pareto concentration in financial services Cx data; RBI 2024–25)

Business Goal

Reduce payment-related Cx ticket volume by 15% without degrading payment completion rates or increasing session abandonment beyond acceptable variance.

02 User Segmentation & Hypothesis

Core Insight

Not all users need the same experience. Friction tolerance correlates with transaction value. A user paying ₹500 for a credit card minimum wants speed. A user clearing a ₹1.2L income tax liability wants proof.

Segmentation Framework

SegmentTransaction ValuePsychologyCurrent ExperienceProposed Change
Low-Anxiety<₹25KRoutine, convenience-focusedInstant success (0.5s)No change
High-Anxiety≥₹25KLoss-averse, security-focusedInstant success (0.5s)Add processing UI (2.5s)

Why the ₹25K Threshold?

  • ₹25K represents approximately 8–10% of India's median urban household monthly income — the threshold at which Kahneman's loss-aversion research (Prospect Theory, 1979) shows anxiety response becomes acute and disproportionate to the actual financial risk
  • Captures naturally high-stakes Indian payment categories: income tax instalments, large credit card bill payments, and rent advances — all structured around monthly financial cycles where users have limited margin for perceived error
  • Represents ~18% of CRED transaction volume but an estimated 64% of payment verification support tickets (est. — consistent with Pareto concentration documented in fintech Cx literature)

Hypothesis

By implementing the “Labor Illusion” — showing visible work during payment processing — we can reduce anxiety-driven support tickets for high-value transactions by ≥15% without impacting payment success rates or session completion.

Behavioral Psychology Foundation

Labor Illusion — Buell & Norton, 2011

Users value outcomes more when they see work being done, even when the underlying process is unchanged. Operational transparency increases perceived value and trust in digital services.

Nielsen's Visibility of System Status — Heuristic #1

Systems should always keep users informed about what is happening through appropriate, timely feedback. A 0.5s completion gives users no anchor for confidence.

03 Experiment Design

Treatment Description

Instead of an instant success confirmation, intercept the payment webhook response and display a 2.5-second state machine UI before rendering the final success screen:

0.0s → 0.8sEncrypting payload...
0.8s → 1.6sSecuring bank gateway...
1.6s → 2.5sPayment successful ✓

Key Technical Details

  • Backend payment processing unchanged — still completes in <0.5s
  • Frontend state machine adds an artificial delay to the success screen only
  • Non-blocking: user can navigate away; state persists on return
  • Success confirmation cached locally before animation begins

Test Parameters

ParameterValue
Duration2 weeks
Split50/50 randomized at user level (sticky assignment)
ScopeTransactions ≥₹25K only
Sample Size84,000 transactions (42K control, 42K treatment)
RandomizationUser-level — consistent experience across sessions

Why 2.5 Seconds?

Three delay durations were evaluated in a pre-experiment: 1.5s, 2.5s, and 3.5s. The 2.5s variant produced the optimal trust-to-speed trade-off. The 1.5s delay was too subtle to register as meaningful effort. The 3.5s delay crossed the mobile UX abandonment threshold — users began tapping away expecting an error state. The 2.5s window sits below the 3-second mobile UX abandonment threshold while being long enough to create perceptible system status.

04 Metrics Framework

Primary Metric

Cost to Serve — Payment Verification Cx Tickets per 10K Transactions

Target: −15% reduction  ·  Measurement: 7-day rolling average

Guardrail Metrics

  • Payment Success Rate — must remain flat (no degradation)
  • Session Drop-off Rate — must not increase by more than 0.5 percentage points

Secondary Metrics (Pre-specified, Observational)

  • Post-Payment NPS for >₹1L segment — tracked to detect any trust uplift beyond ticket reduction; not a decision metric

Counter-Metrics (Expected to Change)

Time to Complete Payment will increase by 2.5 seconds. This is intentional and acceptable — it is the mechanism, not a side effect.

Results

MetricControlTreatmentChangeSignificance
Cx Tickets / 10K Transactions180140−22%p < 0.01 ✓
Payment Success Rate97.8%97.9%+0.1ppp = 0.62 (NS)
Session Drop-off Rate2.1%2.3%+0.2ppp = 0.34 (NS)
Avg. Time to Complete0.6s3.1s+2.5sExpected
Post-Payment NPS (>₹1L)Baseline+8 points+8p < 0.05 ✓
05 Engineering Edge Cases

India's mobile environment — variable network quality, aggressive app lifecycle management, high bank gateway latency at peak hours — means these failure modes are common, not hypothetical. Each was mapped with a specific mitigation before shipping.

EDGE 01Slow Bank Gateway (Real delay >2.5s)
ProblemActual payment takes 8s due to bank-side latency.
SolutionDynamic delay absorption — the UI state machine adapts in real-time, slowing the animation proportionally to actual processing time.
ResultUser sees smooth progressive feedback; never encounters a "stuck" state.
EDGE 02Network Drop During Artificial Delay
ProblemUser loses connectivity after payment clears but before the success screen renders.
SolutionMulti-channel fallback: push notification + SMS receipt + cached local state shown on next app open.
ResultUser is never left in ambiguity about transaction status.
EDGE 03User Force-Quits App Mid-Animation
ProblemUser closes the app during the 2.5s delay period.
SolutionSuccess state written to local storage before animation starts; shown on next app open. Analytics flag: "interrupted_success_state" for behavioral tracking.
ResultPayment confirmed on re-launch; no duplicate ticket generated.
EDGE 04Duplicate Payment Risk
ProblemUser believes payment failed and taps "Pay Again" during the delay.
SolutionPayment button disabled during state machine execution + idempotency key on all payment requests.
ResultDuplicate charges prevented at both UI and API layers.
06 Results & Analysis

Primary Outcome

✓ Achieved 22% reduction in Cx tickets — exceeded the 15% target

Guardrail Checks

  • Payment success rate flat — no degradation (p = 0.62, not significant)
  • Session drop-off within acceptable variance (+0.2pp, p = 0.34, not significant)

Unexpected Insight 1 — Transaction Value Correlation

Transaction BandCx Ticket Reduction
₹25K – ₹50K−18%
₹50K – ₹1L−24%
₹1L+−31%

Learning: Higher stakes = greater benefit from reassurance. The 2.5s delay had disproportionately large impact at the highest transaction bands.

Unexpected Insight 2 — First-Time vs. Repeat Users

User TypeCx Ticket Reduction
First-time payers−35%
Repeat payers (3+ transactions)−12%

Learning: Trust builds over time. First-time high-value payers derive the most benefit — a strong signal for the Phase 3 personalization layer.

Unexpected Insight 3 — Platform Differences

PlatformCx Ticket Reduction
iOS−25%
Android−20%

Learning: Minimal platform variance. The behavioral effect is consistent across devices.

Estimated Cost Impact (based on benchmark assumptions above)

MetricEstimated Value
Monthly Cx cost reduction~₹1.21L (22% of ~₹5.5L est. baseline)
Projected annual savings~₹14.5L (directional; scales with actual ticket volume)
Engineering investment~2 weeks development time
Payback period<1 month (on benchmark assumptions)
07 Rollout Plan
Phase 1: Full RolloutWeek 1–2
  • Recommend shipping to 100% of users for transactions ≥₹25K
  • Monitor daily Cx ticket dashboards
  • Set up automated alerts for guardrail metric degradation
Phase 2: Dynamic Delay ScalingMonth 2
  • ₹25K–50K: 2.0s delay
  • ₹50K–1L: 2.5s delay
  • ₹1L+: 3.0s delay
Phase 3: Personalization LayerMonth 3
  • First-time payers: 3.0s (highest anxiety)
  • Repeat payers (3+ txns): 1.5s (trust established)
  • Power users (10+ txns): 0.5s (effectively opt-out)
Phase 4: Messaging A/B TestMonth 4
  • Test copy: "Encrypting payload" vs. "Verifying payment" vs. "Processing securely"
  • Measure Cx ticket impact and user sentiment per variant
08 Risks & Mitigations
RiskProbabilityImpactMitigation
Users perceive delay as a performance issueMediumMediumClear progressive messaging; education during onboarding for first-time high-value payers
Competitor launches "instant payment" marketingLowLowCRED's brand positioning is trust and premium experience — not raw speed
Edge case failures damage trustLowHighMulti-channel fallback systems (SMS, push notification, cached local state)
Regulation requires instant transaction confirmationVery LowHighFeature disabled via feature flag with no code changes required
09 Reflection

Key Product Lessons

Engineering Excellence ≠ User Confidence

Sub-second latency was an engineering win but a psychology loss for high-anxiety transactions. Users need to see effort to trust outcomes. Speed and reassurance are not always aligned.

Friction Can Be Beneficial

Strategic friction builds trust when applied to high-anxiety moments. The key is segmentation: add friction where anxiety exists, remove it where speed matters. A blunt 'slow everything down' policy would have been wrong; a targeted intervention was right.

Metrics Must Tell the Full Story

Primary + Guardrails + Counter-metrics = complete picture. Without guardrail metrics, we might have optimized for ticket reduction while unknowingly degrading payment completion rates.

Edge Cases in India's Mobile Environment

Network drops, slow connections, and force-quits are not rare edge cases in the Indian mobile context — they are common occurrences. Robust failure handling separates a clean experiment from a shippable feature.

What I'd Do Differently

  • Run for 4 weeks to capture full monthly payment cycles (income tax, rent, and credit card due dates are monthly events)
  • A/B test the messaging copy variants upfront — copy is a material variable, not an afterthought
  • Measure long-term retention impact: does payment trust correlate with 90-day LTV?
  • Interview users who still contacted support despite the treatment UI — what failure mode did we miss?
Appendix

A. Experiment Timeline

WeekActivity
Week 1Experiment design + spec
Weeks 2–3Implementation (frontend state machine + edge case handling)
Weeks 4–5A/B test run
Week 6Analysis + shipping decision
Week 7Full rollout to 100% of ≥₹25K transactions

B. References

  • [1]Buell, R. W., & Norton, M. I. (2011). "The Labor Illusion: How Operational Transparency Increases Perceived Value." Harvard Business School Working Paper 11-109.
  • [2]Nielsen, J. (1994). "10 Usability Heuristics for User Interface Design." Nielsen Norman Group. nngroup.com/articles/ten-usability-heuristics/
  • [3]Kahneman, D., & Tversky, A. (1979). "Prospect Theory: An Analysis of Decision under Risk." Econometrica, 47(2), 263–292. — Foundational basis for loss aversion in high-stakes financial transactions.
  • [4]Buell, R. W., Kim, T., & Tsay, C. J. (2017). "Creating Reciprocal Value Through Operational Transparency." Management Science, 63(6), 1673–1695. — Extends the Labor Illusion to show that transparency generates reciprocal trust and effort from customers.
  • [5]Ariely, D. (2008). Predictably Irrational: The Hidden Forces That Shape Our Decisions. HarperCollins. — Chapters 4 & 9 on price anchoring and expectation-setting in high-value transactions.
  • [6]RBI (2025). "Digital Payments Intelligence Platform — Annual Report." Reserve Bank of India. — Basis for understanding UPI payment context and the Indian digital payments landscape.

Disclaimer: This is a hypothetical growth experiment created for portfolio purposes. It demonstrates product thinking, experimentation rigor, and behavioral psychology application — not an actual CRED feature or internal document.

Back to portfolio