# CRED Beneficial Friction Experiment
## Growth Memo: Reducing Payment Support Tickets Using Behavioral Psychology

**Author:** Yatin Khar
**Date:** May 2026
**Status:** Hypothetical A/B Test (Portfolio Exercise)
**Category:** Growth / 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. Our 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.

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. That cognitive gap converted directly into support volume.

### Cost Breakdown

| Metric | Value |
|--------|-------|
| Payment verification tickets per 10K high-value transactions | 180 |
| Average handling cost per ticket (avg ~15 min handling time, incl. escalations) | ₹180 |
| Monthly operational burden (~170K high-value txns/month) | ₹5.5L |
| High-value segment share of tickets vs. volume | 64% of tickets from 18% of volume |

### 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

| Segment | Transaction Value | Psychology | Current Experience | Proposed Change |
|---------|------------------|------------|-------------------|-----------------|
| Low-Anxiety | <₹25K | Routine, convenience-focused | Instant success (0.5s) | No change |
| High-Anxiety | ≥₹25K | Loss-averse, security-focused | Instant success (0.5s) | Add processing UI (2.5s) |

### Why the ₹25K Threshold?

- Cx ticket rate inflection point identified in data analysis
- Captures high-stakes payments: income tax, large credit card bills, rent
- Represents 18% of volume but 64% of payment verification support tickets

### 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.8s   Encrypting payload...
0.8s → 1.6s   Securing bank gateway...
1.6s → 2.5s   Payment 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

| Parameter | Value |
|-----------|-------|
| Duration | 2 weeks |
| Split | 50/50 randomized at user level (sticky assignment) |
| Scope | Transactions ≥₹25K only |
| Sample Size | 84,000 transactions (42K control, 42K treatment) |
| Randomization | User-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.

---

## 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

| Metric | Control | Treatment | Change | Significance |
|--------|---------|-----------|--------|--------------|
| Cx Tickets / 10K Transactions | 180 | 140 | −22% | p < 0.01 ✓ |
| Payment Success Rate | 97.8% | 97.9% | +0.1pp | p = 0.62 (NS) |
| Session Drop-off Rate | 2.1% | 2.3% | +0.2pp | p = 0.34 (NS) |
| Avg. Time to Complete | 0.6s | 3.1s | +2.5s | Expected |
| Post-Payment NPS (>₹1L) | Baseline | +8 points | +8 | p < 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.

### Edge Case 01: Slow Bank Gateway (Real delay >2.5s)

- **Problem:** Actual payment takes 8s due to bank-side latency
- **Solution:** Dynamic delay absorption — the UI state machine adapts in real-time, slowing the animation proportionally to actual processing time
- **Result:** User sees smooth progressive feedback; never encounters a "stuck" state

### Edge Case 02: Network Drop During Artificial Delay

- **Problem:** User loses connectivity after payment clears but before the success screen renders
- **Solution:** Multi-channel fallback: push notification + SMS receipt + cached local state shown on next app open
- **Result:** User is never left in ambiguity about transaction status

### Edge Case 03: User Force-Quits App Mid-Animation

- **Problem:** User closes the app during the 2.5s delay period
- **Solution:** Success state written to local storage before animation starts; shown on next app open. Analytics flag: "interrupted_success_state" for behavioral tracking
- **Result:** Payment confirmed on re-launch; no duplicate ticket generated

### Edge Case 04: Duplicate Payment Risk

- **Problem:** User believes payment failed and taps "Pay Again" during the delay
- **Solution:** Payment button disabled during state machine execution + idempotency key on all payment requests
- **Result:** Duplicate 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 Band | Cx Ticket Reduction |
|-----------------|---------------------|
| ₹25K – ₹50K | −18% |
| ₹50K – ₹1L | −24% |
| ₹1L+ | −31% |

*Learning: Higher stakes = greater benefit from reassurance.*

### Unexpected Insight 2 — First-Time vs. Repeat Users

| User Type | Cx 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

| Platform | Cx Ticket Reduction |
|----------|---------------------|
| iOS | −25% |
| Android | −20% |

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

### Cost Impact

| Metric | Value |
|--------|-------|
| Monthly Cx cost reduction | ₹1.21L (22% of ₹5.5L) |
| Projected annual savings | ₹14.5L |
| Engineering investment | 2 weeks development time |
| Payback period | <1 month |

---

## 07 — Rollout Plan

### Phase 1: Full Rollout (Week 1–2)
- Ship to 100% of users for transactions ≥₹25K
- Monitor daily Cx ticket dashboards
- Set up automated alerts for guardrail metric degradation

### Phase 2: Dynamic Delay Scaling (Month 2)
- ₹25K–50K: 2.0s delay
- ₹50K–1L: 2.5s delay
- ₹1L+: 3.0s delay

### Phase 3: Personalization Layer (Month 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 Test (Month 4)
- Test copy: "Encrypting payload" vs. "Verifying payment" vs. "Processing securely"
- Measure Cx ticket impact and user sentiment per variant

---

## 08 — Risks & Mitigations

| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|
| Users perceive delay as a performance issue | Medium | Medium | Clear progressive messaging; education during onboarding for first-time high-value payers |
| Competitor launches "instant payment" marketing | Low | Low | CRED's brand positioning is trust and premium experience — not raw speed |
| Edge case failures damage trust | Low | High | Multi-channel fallback systems (SMS, push notification, cached local state) |
| Regulation requires instant transaction confirmation | Very Low | High | Feature 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

| Week | Activity |
|------|----------|
| Week 1 | Experiment design + spec |
| Weeks 2–3 | Implementation (frontend state machine + edge case handling) |
| Weeks 4–5 | A/B test run |
| Week 6 | Analysis + shipping decision |
| Week 7 | Full 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.