A second-hand marketplace needs a traceable case record that connects evidence, decisions, returns and payment outcomes. When a buyer requests a refund, support should compare the original listing with the evidence from both parties. Approval is a business decision; returning an item and completing a refund are separate events. One “completed” label cannot reliably describe all three.
This guide is for operators selecting software for a South African second-hand marketplace. For the wider launch scope, start with our guide to building a second-hand marketplace in South Africa.
Cover illustration: inspecting a returned second-hand item.
Define what the platform can actually resolve
A listings platform that connects buyers and sellers has different responsibilities and capabilities from one that also integrates payments, delivery and after-sales support. A listings service can record complaints, retain evidence and address account violations. It cannot treat an off-platform bank transfer as a successful platform refund. An integrated marketplace must still confirm what its payment provider supports and who is responsible for each review decision.
Before development, document eligible reasons for a request, how application and response deadlines work, and how item prices, shipping and service fees are handled. Confirm these rules for the relevant parties, goods, contracts and applicable requirements. Another marketplace's deadlines are not automatically yours.
For example, Yaga's guidance on buyer dissatisfaction considers a significant mismatch with the listing, an on-platform purchase, notification timing and whether receipt has been confirmed. The software lesson is to preserve the records needed for those decisions, rather than copy Yaga's policy.
Save evidence before a dispute starts
The current listing may no longer show what the buyer saw when ordering. Link each support case to an order snapshot, then append later submissions as separate records:
Order snapshot: photos, disclosed defects, agreed price, delivery method and the policy version that applied at purchase.
Buyer request: issue category, explanation, requested resolution, photos and submission time.
Seller response: replies, supporting materials and timestamps, with an edit history.
Delivery and return evidence: tracking, receipt information or agreed collection handover records. Distinguish provider-supplied information from manual uploads.
Support needs to compare what was described with what was received. A photograph alone cannot establish every fact. Missing evidence or a late reply should trigger the documented reminder, escalation or review process, with a recorded reason. Restrict access to people who need the material for the case; do not expose addresses or contact details to unrelated roles.
Separate dispute, return and refund states
A practical case screen should show three independent tracks:
Dispute: received → awaiting evidence → under review → decision recorded. Keep appeals as additional records.
Return: not required or not arranged → awaiting dispatch → in transit → awaiting inspection → inspection outcome.
Refund: not initiated → awaiting submission → processing with provider → provider-confirmed success, failure or outcome requiring investigation.
This example is still awaiting the seller's evidence. No return has been arranged and no refund has been initiated. Separate states help support explain what is happening next.
A review may lead to an agreed partial refund, a return followed by a refund, a refusal with reasons, or further review. Record the evidence, operator, time and notification for each decision. Whether a return is required before a refund depends on the applicable policy; the system should not force that sequence onto every case.
Reconcile payments and prevent duplicate refunds
An approved case still needs a payment action linked to the original transaction, amount, provider and outcome. Payfast's merchant refund overview describes full and partial refunds. Its refund instructions also explain that sufficient merchant wallet funds are needed and that the refund route and timing can vary by payment method and other factors. Do not tell a buyer that funds have arrived merely because a review was approved.
Ask suppliers to demonstrate these controls:
Amount breakdown: show the item price, original shipping, return shipping and service fees separately, with the basis for each decision. Refund limits must account for successful refunds and amounts still being processed.
Duplicate prevention: assign a stable reference to each refund action. After a repeated click or timeout, check the original outcome before retrying.
Exception handling: insufficient funds, provider failures and unknown results need an owner and an investigation queue, not a success label.
Permissions and audit: separate complaint intake, decision approval and refund execution. Corrections should preserve the previous record.
If the business needs to delay seller settlement, confirm that capability with the payment arrangement and relevant contract separately. A support-case module does not itself provide escrow or the ability to freeze money.
Test the supplier with five practical scenarios
The seller edits the listing before a complaint. Support can still retrieve the original order snapshot and distinguish later changes.
Both parties agree to a partial refund. The system retains agreement, the amount breakdown and the original payment reference. A later request cannot cause an excessive refund.
The connection times out during submission. Refreshing or clicking again does not create a second refund; staff can check the original request.
A return is delivered but its condition is disputed. Delivery does not automatically close the case, and inspection evidence can still be added.
A support agent without payment permissions attempts a refund. The system blocks the financial action while allowing evidence collection and communication updates.
HUACODE's second-hand trading marketplace system is a starting point for evaluating listing, publishing and communication capabilities. The case-management and refund workflows described here are proposed requirements, not confirmation that every feature is included or that a Payfast integration already exists.
Use HUACODE's requirements consultation to share your payment method, delivery model and refund rules. Ask the supplier to distinguish existing features from configuration or development work, and agree on acceptance scenarios before committing to a scope.
Sources checked: 16 October 2026. Yaga and Payfast documentation is cited as workflow reference material. Reconfirm applicable policies and payment capabilities during implementation.