“To Be Failed” Orders & Credit Deduction Logic
For Cashkr Vendor App, Ops, CX, and Finance Teams
1. Overview
A “To Be Failed” order is any order where the vendor cannot complete pickup successfully due to:
Customer issues
Vendor issues
Device mismatch
Incorrect inspection
SLA breach
Fraud triggers
These orders require manual review and can lead to credit deduction or refund depending on the root cause.
2. What is a “To Be Failed” Order?
An order becomes To Be Failed when:
Vendor tried to fulfill the order but could not complete it.
Examples:
Customer refused revised price
Device does not match what customer selected
Customer unavailable after appointment
Payment not possible due to customer issue
Vendor found device defective beyond what was claimed
Customer changed mind at the last minute
Customer unreachable after vendor arrival
Fraud suspicion (IMEI mismatch, tampering, sealed box claims)
These are NOT instantly failed —
Ops verifies before marking order as Failed and deciding credit deduction/refund.
3. Types of “To Be Failed” Reasons
There are two categories:
A. Customer-Side Fail Reasons (Vendor Not At Fault)
These DO NOT deduct credits.
Reason | Explanation |
|---|---|
Customer Rejected Final Price | Actual condition lower than claimed |
Customer Not Responding | Multiple failed contact attempts |
Customer Address Wrong | Vendor reached but not found |
Customer Not Available | Customer not at home |
Customer Changed Mind | Customer opted not to sell |
OTP Not Provided | Customer refuses or delays payment OTP |
Device Not Charged / Not Accessible | Can’t verify device |
Customer Asking Higher Price | Beyond platform price |
Result:
✔ Credits returned
✔ Wallet untouched
✔ Vendor performance unaffected
B. Vendor-Side Fail Reasons (Vendor At Fault)
These DO lead to credit deduction and sometimes SLA penalty.
Vendor Mistake | Explanation |
|---|---|
Wrong Inspection | Marking wrong defects intentionally or mistakenly |
Price Manipulation | Trying to reduce price to benefit personally |
Not Visiting Customer | Marking status falsely without visiting |
Arrived Late Beyond SLA | Customer cancels due to vendor delay |
Rude Behaviour | Customer reports behaviour issue |
Device Taken Without Payment | Serious fraud |
Attempting Offline Payment | Google Pay / Cash / PhonePe |
Multiple Cancels by Vendor | Pattern of poor behaviour |
Failing to Understand Device Condition | Inaccurate inspections |
Asking for Extra Charges | Illegal behaviour |
Result:
✖ Credits deducted
✖ SLA strike applied
✖ Vendor may be put on hold
✖ Repeat offences → deactivation
4. Credit Deduction Logic
When an order is unlocked, credits are deducted instantly.
Situation 1 → Vendor NOT at fault
Credits should be refunded fully after Ops review.
Situation 2 → Vendor IS at fault
Credits are NOT refunded.
General rule:
If vendor made a mistake → credits deducted
If customer caused the failure → credits refunded
5. Wallet Deduction Logic
Wallet is NOT involved until payment is attempted.
Wallet is refunded ONLY when:
Vendor paid customer (rare scenario before failure)
Ops changes order to failed and triggers refund
Payment must be reversed
Wallet is NOT touched in most failure cases.
6. Internal Review Flow (Ops Team)
Every “To Be Failed” order goes through 5-step process:
Step 1: Vendor submits fail reason
Vendor selects a reason + short explanation.
Step 2: Ops verifies
Ops checks:
Call logs
Customer statement
Vendor GPS logs
Inspection entry
Chat/ticket reports
Step 3: Decide who is at fault
Vendor fault → Deduction
Customer fault → Refund
Step 4: Update vendor balance
Adjust credits
Adjust wallet (if needed)
Step 5: Status Updated to FAILED
Order moves out of “To Be Failed”
SLA updated
Vendor notified
7. Examples to Understand Deduction
Example 1 (Customer Rejects Price)
Vendor is correct → Credits refunded.
No penalty.
Example 2 (Vendor arrives late, customer cancels)
Vendor fault → Credits NOT refunded.
1 SLA strike.
Example 3 (Device mismatch)
Customer chose wrong options → Credits refunded.
If vendor claims wrongly → Deduct credits.
Example 4 (Vendor tries offline payment)
Major violation →
Credits deducted + vendor put on hold + possible deactivation.
8. When Credits Must Always Be Deducted
Credits will always be deducted if:
✔ Vendor lies about inspection
✔ Vendor marks “Customer Not Available” without going
✔ Vendor mixes IMEI
✔ Behaviour complaint from customer
✔ Vendor tries to negotiate outside app
✔ Vendor forces customer to accept price
✔ Vendor delays pickup intentionally
✔ Vendor repeatedly fails orders
9. When Credits Must Always Be Refunded
Credits must be returned when:
✔ Customer unreachable
✔ Customer wrong device details
✔ Customer changed mind
✔ Customer refuses OTP
✔ Customer unavailable after agreed time
✔ Customer only wants higher price
✔ Customer cancels before inspection
10. Vendor Training Summary (Use in Workshops)
Credits Deducted If:
Vendor mistake
Vendor behaviour issue
Vendor fraud
Vendor SLA violation
Credits Refunded If:
Customer issue
Wrong details provided by customer
Legit mismatch
Price disagreement
Wallet Refund:
Only when payment already happened
Never automatic
Only through Admin panel