Operational accountability

Service & Incident Commitments

The operational standards Keshopay follows for transaction integrity, availability, incident escalation, customer communication, recovery, and evidence preservation.

Review draft: complete the BRELA registration number, TIN, business licence number, address, email, and toll-free contact fields before publishing this document as an approved customer notice.

Service principles

Protect transaction integrity before speed: an unknown outcome is never automatically re-initiated or rerouted.
Keep sandbox and production credentials, data, providers, and status strictly separated.
Apply maker-checker approval to protected production actions and retain attributable audit evidence.
Show customer amounts and fees before confirmation and preserve the accepted pricing record.
Communicate material incidents clearly without exposing secrets or unverified conclusions.

Reliability objectives

Keshopay measures payment success, initiation acknowledgement, callback lag, recovery, webhook delivery, reconciliation matching, and complaint first response. Current internal baseline objectives include 98% terminal-payment success over 24 hours, 95% of provider attempts acknowledged within 10 seconds, 99% of callbacks processed within 60 seconds of receipt, and 97% webhook delivery success over 24 hours.

These are operational objectives, not a promise that every transaction or provider will meet them. A binding merchant service level, service credit, exclusion, and maintenance window must appear in the signed merchant agreement.

Incident classification and ownership

Level	Example impact	Escalation obligation
Critical	Widespread inability to pay, confirmed financial-integrity or security risk	Incident commander, engineering, operations, security, provider, executive and customer-communications owners engaged immediately
High	Material degradation, delayed callbacks, reconciliation or payout risk	Technical and operational owner engaged; affected merchants notified when impact is confirmed
Standard	Limited defect with safe workaround and no financial-integrity concern	Tracked through normal support and release process with an accountable owner

Customer and merchant communication

For a confirmed material incident, communications identify the affected capability and environment, known customer impact, safe action to take, what users must not do, the next update point, and the recovery confirmation. We do not declare transactions failed or advise repayment while outcomes remain unknown.

Merchants must maintain named operational and emergency contacts. Consumers receive transaction or complaint updates through the contact connected to the relevant record. Security communications never request a PIN, OTP, password, recovery code, API key, or webhook secret.

Recovery and rollback

Payment and payout workers use one-time claims so a restart does not create a second provider initiation.
Provider outages use maintenance exclusion before a new initiation; already-sent transactions stay with their original provider for status recovery.
Queue recovery preserves and drains durable jobs once.
Credential rotation retains a controlled rollback point and revokes superseded access after validation.
Database and secret-store restoration must be tested against encrypted backups and production-like staging before launch.

Security and privacy escalation

Suspected unauthorised access, credential exposure, malicious files, personal-data breach, fraudulent transactions, or integrity failure is escalated to security and compliance. Processing may be restricted while evidence is preserved. Notifications to the Personal Data Protection Commission, Bank of Tanzania, affected providers, merchants, or individuals are made in the form and timeframe required by law and the assessed risk.

Service concerns and complaints

Operational questions may be sent to [insert customer-support email]. A service concern involving customer harm, financial loss, an erroneous debit, excess charge, unresolved delay, privacy, or unfair treatment may be lodged through the Complaints & Redress Procedure without charge.

Legal entity:: Kesho Technologies Company Limited
BRELA registration number:: [insert BRELA company registration number]
TIN:: [insert Tanzania Revenue Authority TIN]
Business licence number:: [insert business licence number]
Regulatory role:: Kesho Technologies Company Limited does not hold or claim a direct Bank of Tanzania payment-service licence or approval. Regulated payment processing is provided through Malipo Pay and AzamPay under their applicable licences and approvals, where each provider integration is enabled and operationally certified.
Address:: [insert registered physical and postal address, Tanzania]
Email:: [insert customer-support email]