Software Development
Payments, SMS and ID Checks: Integrating South African Services Into Your Business Software
Most business software is only as useful as the systems it connects to. A beautifully designed job tracker still frustrates staff if every payment has to be checked manually in a bank portal, every client notification is sent by hand, and every identity number is retyped from a scanned document.
For South African organisations, the most common integrations are payments, SMS and email notifications, identity checks, and existing databases or accounting systems. This guide is for MDs and IT or operations managers planning a new system, or trying to fix one that does not talk to anything else.
Why integration matters more than features
When a system is not integrated, people become the integration. Someone copies a payment reference from one screen to another. Someone exports a CSV every Friday. Someone phones the client because the system cannot send a message.
That manual glue is slow, error-prone and invisible in planning. It rarely appears in a project quote, but it shows up every day in staff time. Good integration means information is captured once and flows to where it is needed.
1. Payment gateways
South African businesses have several local payment options, including card gateways such as Paystack, instant EFT providers such as Ozow, and bank-led options such as Capitec Pay. Cyber Developers has integrated processors like these where a product required them.
What to plan for:
- Server-side confirmation. Never mark something as paid just because the customer's browser came back from the payment page. The system should confirm the payment through the provider's signed callback (webhook) or API before releasing goods, tickets or services.
- Failed and abandoned payments. Customers close tabs, banks time out and cards get declined. The system needs clear states such as pending, paid, failed and refunded, and staff need to see them.
- Reconciliation. Finance will ask which payments belong to which invoice. Store the provider's reference against your own record so reconciliation is a lookup, not an investigation.
- Fees and settlement. Gateway fees and settlement times differ between providers. Choose based on your customers' habits and your cash-flow needs, not only on the integration effort.
2. SMS and email notifications
Notifications are often the integration users notice most. A client receiving "your order has been dispatched" or a technician getting "new job assigned" changes how a system feels.
What to plan for:
- Trigger on real events. Send messages when a record actually changes state, not on a schedule that might be out of date.
- Avoid notification storms. If every small update sends an SMS, people stop reading them. Decide which events genuinely need a message.
- Consent and POPIA. Marketing messages need consent and an opt-out. Operational messages, such as an appointment reminder, still need care with personal information. Keep a record of what was sent and to whom.
- Delivery failures. Numbers change and emails bounce. Log failures so someone can follow up instead of assuming the message arrived.
3. Identity checks
Many South African processes involve identity numbers: onboarding clients, registering learners or tenants, or verifying drivers and service providers.
What to plan for:
- Validate the format first. A South African ID number has a structure and a checksum. Validating it on capture catches typing errors before they cause problems later.
- Verification versus validation. Checking that a number is well formed is not the same as checking that it belongs to that person. Formal verification usually requires an authorised third-party service, and it should be scoped and budgeted separately.
- Protect the data. ID numbers are personal information under POPIA. Limit who can see them, avoid exporting them unnecessarily and log access.
4. Existing databases and accounting systems
Few organisations start with a blank slate. There may be an existing SQL database, an accounting package or a legacy system that still holds important records.
What to plan for:
- Decide the source of truth. For each type of record, which system owns it? Customers might live in the new system while invoices stay in the accounting package. Ambiguity here causes duplicate and conflicting data.
- One-way or two-way sync. Two-way synchronisation is far more complex than one-way. Only build it where the process genuinely needs it.
- Migration as a project step. Importing historical data needs cleaning, mapping and testing. Plan for it explicitly.
Common integration mistakes
- Treating integration as an afterthought. Discuss integrations during discovery, because they shape the data model.
- Trusting the client side. Payment status and permissions must be enforced on the server.
- No error handling. External services fail. The system should retry where safe, record the failure and alert someone.
- Hard-coding credentials. API keys belong in secure configuration, never in source code or shared documents.
- No monitoring. If a webhook stops arriving, someone should know the same day, not at month-end.
A simple planning checklist
Before you brief a developer, list:
- Every external system the process touches today, including manual ones such as bank portals.
- Which events should trigger a payment, message or check.
- Who needs to see the result of each integration.
- What should happen when an external service is down.
How Cyber Developers can help
Cyber Developers builds systems integration into the business software we design: payments, SMS, identity checks and existing SQL databases, wired in so information is never retyped. If your team is acting as the glue between systems, tell us about the process and we will suggest a practical way to connect it.