Handling Refunds (Wallet & Credits Reversal Flow)

Purpose: For Finance, Ops, CX, Vendor Ops & Business Development/Management Teams

1. Purpose of This Module

To standardize:

Refund approval
Wallet refunds to vendors
Credit reversals
Customer payment corrections
Internal auditing of reversal actions

This ensures:

✔ No financial mistakes
✔ Clear accountability
✔ Accurate balances
✔ Prevention of fraud
✔ Smooth customer + vendor issue resolution

2. Types of Refunds in Cashkr

Cashkr deals with three types of refunds:

A. Vendor Wallet Refunds

When vendors paid customers via Wallet but the order is reversed or corrected.

Examples:

Wrong payment
Duplicate payment
Ops-approved return
Vendor refund due to system error

B. Vendor Credit Reversal

Credits that were deducted for unlocking an order and must be returned.

Examples:

Order wrongly assigned
System glitch during unlock
Vendor not at fault (Ops confirmation)
Return flow (vendor not responsible)

C. Customer Refunds

Very rare, since customers are paid (not paying Cashkr).
Used only when:

Payment sent to wrong UPI
Duplicate payout by vendor
Customer did not receive amount due to bank errors

Refund amount is re-sent to customer after Finance verification.

3. When Refunds Are Allowed

Refunds are processed ONLY under these verified cases:

1. Order Cancelled After Payment (Return Flow Approved)

Ops confirms vendor fault or system fault
Device returned to customer
Wallet + Credits reversed

2. Wrong Payment by Vendor

Incorrect UPI entered
Double payment
Payment mismatch
Wrong amount paid

3. System Errors / App Bugs

Payment triggered twice
Credits deducted multiple times
Wallet deducted without payout

4. Vendor Needs Reversal After Ops Decision

Vendor not responsible for failure
Ops approves restore of credits

5. High-Level Correction from Finance/Management

For audit corrections
Ledger misalignment
Exception-based approvals

4. Refund Approval Authority Levels

Refund Type	Approval Required
Credit Reversal (Low Amount)	Vendor Ops
Credit Reversal (High Amount)	Vendor Ops Manager
Wallet Refund (< ₹5,000)	Finance
Wallet Refund (> ₹5,000)	Finance Head + Ops Manager
Customer Refund	Finance Head + Ops + Management
Fraud/Suspicious Cases	CEO / Compliance Team

No team may bypass these rules.

5. Step-by-Step Refund Process (Wallet Reversal)

This applies when vendor wallet must be credited back.

Step 1 — CX/Ops Identifies Case

Collect:

Order ID
Vendor ID
Payment proof
Reason for reversal
Vendor explanation

Add internal notes in Admin Panel.

Step 2 — Ops Validates the Case

Ops must check:

Payment logs
Order reason
Vendor performance
Inspection correctness

If approved → escalate to Finance.

Step 3 — Finance Verifies Payment

Finance checks:

Bank statement
UPI transaction logs
System payout logs
Duplicate or incorrect payments

If confirmed → proceed.

Step 4 — Open Admin Panel → Wallet Adjustments

Path:
Finance Panel → Wallet Adjustments → Add Wallet Balance

Fields:

Vendor ID
Amount
Reason (must be detailed)
Reference ID (UTR, Order ID)

Step 5 — Add Refund Reason in Notes

Mandatory for audit and investigation.

Step 6 — Vendor Notified Automatically

Vendor receives:

“Your Wallet has been credited with ₹____ for Order ID ______.”

6. Step-by-Step Credit Reversal Process (Order Unlock Credits)

Step 1 — Ops Approves Reversal

Reasons may include:

Vendor not at fault
System error
Incorrect failure marking
Return approved

Ops adds internal notes.

Step 2 — Vendor Ops Confirms Vendor Eligibility

Vendor must:

Not be fraudulent
Not be on hold
Have valid reason

Step 3 — Open Admin Panel → Credits Module

Path:
Vendor → Credit Management → Add Credits

Fields:

Vendor ID
Number of credits
Reason
Order ID reference

Step 4 — Credits Reversed

System updates balance instantly.

Vendor receives notification:

“Your Credits have been restored successfully.”

7. Customer Refund Flow (Rare Cases)

This is only for payment misrouting.

Step 1 — CX Logs Issue

Customer shares:

UTR screenshot
Payment delay details
Wrong UPI issue

Step 2 — Finance Validates Transaction

Check:

Vendor payout logs
Bank processing delays
Wrong beneficiary

Step 3 — Refund Approved

This requires Finance + Ops Manager sign-off.

Step 4 — Refund Reinitiated

Payment is re-sent to customer’s correct UPI ID.

Step 5 — Update Admin Panel Notes

Notes MUST include:

Why refund needed
Proof attached
Action taken
Confirmation from Finance

8. Fraud Detection in Refund Requests

Refunds must be denied immediately if:

🚫 Vendor claims false payment issues
🚫 Vendor tries double refund
🚫 Vendor uploads edited screenshots
🚫 Vendor requests reversal without valid reason
🚫 Vendor tries refund for orders marked as To Be Failed due to vendor mistake

Fraudulent vendors must be:

Held
Investigated
Penalized with Credit Deduction
Deactivated if repeated

9. BD Team Responsibilities in Refund Cases

BD Team uses refund data to:

Identify high-failure zones
Identify problematic vendors in specific areas
Highlight cities with poor SLA leading to refunds
Improve coverage and vendor quality in high-refund pincodes

They DO NOT process refunds but use data for area performance analytics.

10. Documentation & Notes (Mandatory)

Every refund must include:

Order ID
Vendor/customer
Amount refunded
Why refund needed
Who approved
Evidence (screenshots/UTR)
Final confirmation from Finance

If notes are missing → Refund is invalid.

11. One-Page Quick Summary (Training Card)

Wallet Refund = Vendor Wallet Balance Returned

Used when vendor overpaid or reversal is approved.

Credit Refund = Commission Credits Returned

Used when vendor not at fault.

Customer Refund = Very rare

Used only for payment misrouting.

Approval Flow:

Ops → Vendor Ops → Finance → Final Approval
Strict verification required
All actions logged for audit