Refund Policy
How refund requests, duplicate payments, missing token deliveries and token-ledger corrections are handled.
This Refund Policy applies to purchases of slipr tokens from slipr, the trading name of the South African sole proprietor identified on the Contact page. It forms part of the Terms of Service.
slipr is offered only in South Africa. Token purchases are offered and processed in South African rand for use with the Service in South Africa.
1. General rule
slipr tokens are prepaid internal service credits used for receipt scanning and related processing. We do not ordinarily provide discretionary cash refunds for:
- tokens that have already been used for a successful scan or user-requested rerun;
- a partially used bundle merely because the user changed their mind after use began;
- free, promotional, bonus, or support-issued tokens;
- dissatisfaction caused only by failing to review or correct extracted bill information; or
- an account suspension or closure resulting from a material breach, except to the extent applicable law requires otherwise.
This general rule does not exclude any right or remedy that cannot lawfully be excluded.
2. Cooling-off and mandatory consumer rights
Where section 44 of the Electronic Communications and Transactions Act 25 of 2002 applies, a consumer may be entitled to cancel an eligible electronic transaction for services within seven days after the agreement was concluded and receive the refund required by law. The statutory cooling-off right may not apply where services began with the consumer’s consent before that period ended.
Other rights may apply under the Consumer Protection Act 68 of 2008, including rights relating to prepaid credits, service quality, failed delivery, misleading conduct, and remedies that cannot be waived by contract.
If a valid statutory cancellation or refund right applies, slipr will provide the remedy and meet the timing required by law. A refund required after a valid ECTA cooling-off cancellation will be initiated within the applicable statutory period, currently no later than 30 days after cancellation.
3. When we will investigate a refund or correction
Contact us promptly if:
- your payment was duplicated;
- Paystack confirmed payment but the purchased tokens were not delivered;
- the amount charged differed from the order you approved;
- a payment was unauthorised;
- we cannot provide the purchased service or token value;
- a token deduction has no corresponding processing record;
- the same successful processing event was charged more than once; or
- you believe a statutory cooling-off or consumer right applies.
Depending on the circumstances and applicable law, we may deliver the missing tokens, restore an incorrect token deduction, re-perform the service, reverse a duplicate transaction, or provide a partial or full cash refund.
4. Scan results and token corrections
Token deductions are based on the processing activity recorded by the Service, not solely on whether a user considers a scan successful. A scan or user-requested rerun may therefore consume tokens even when its result is incomplete, inaccurate, unhelpful, or requires correction, including where image quality, framing, unsupported content, or use of the Service affected the result.
A user’s description of a scan as “failed” does not by itself entitle the user to restored tokens or a cash refund. We will investigate objective ledger issues, such as the same processing event being charged more than once or a deduction having no corresponding processing record. A verified ledger error will ordinarily be corrected with a token adjustment rather than a cash refund.
OCR or AI extraction mistakes do not automatically entitle a user to a cash refund. Users must review and correct the proposed bill. This does not limit a remedy required by law where the Service failed to meet an applicable statutory standard.
5. Partial use and token deficits
Where a bundle has been partly used, any refund assessment will take account of the tokens already consumed and any token deficit created by a completed scan. Promotional tokens are not assigned a cash value.
We do not promise a discretionary pro-rata refund for an unused paid balance. Where applicable law requires a refund or other treatment of unredeemed paid value, we will calculate the available remedy from the relevant purchase allocations, usage history, adjustments, and payment records.
6. Account closure
Account closure does not create an automatic discretionary refund. Before closing an account with unused purchased tokens, contact support@slipr.co.za. We will review the remaining purchased value, pending activity, refunds, disputes, and applicable legal requirements. Unused paid value will be handled as applicable law requires; promotional tokens may be removed.
7. How to make a request
Email support@slipr.co.za and include:
- the email address associated with your slipr account;
- the Paystack transaction reference or payment confirmation;
- the purchase date and amount;
- the number of tokens affected;
- a concise description of the problem and the remedy requested; and
- any supporting screenshot or bank confirmation, with unrelated sensitive information obscured.
We may request reasonable proof of identity or payment authority. We aim to acknowledge and investigate complaints promptly and to provide a substantive response within 15 business days.
8. How approved refunds are paid
Approved cash refunds are normally initiated through Paystack to the original payment method where possible. We do not refund to an unrelated account merely on request.
After Paystack marks a refund as processed, the customer’s bank or payment provider may take additional time to reflect it. Paystack states that this can take up to 10 business days. A refund may require additional customer bank details if the payment rail did not return sufficient account information.
When a cash refund is approved, the corresponding unused purchased tokens will be removed or adjusted so the same value cannot be used and refunded. Refunds, reversals, and chargebacks may create a token deficit where the related tokens have already been consumed.