How to Connect Your Business Software

If your staff spend the first hour of each morning copying figures between your order records, your accounting package and a spreadsheet, you have an integration problem with a known solution. The question is which method, because the difference between a ₦0 native connection and a ₦900,000 custom integration is often just whether you checked the settings page first.

This is a practical guide to the mechanics: the five connection methods and when each is appropriate, how to choose between them, how to map fields without corrupting data, how to test properly, what to do about errors, and what the work costs in Nigeria. The broader question of how to architect a whole integrated system is covered separately.

What connecting software actually involves

Connecting two business systems means agreeing four things: what event starts the transfer, what data moves, how the two systems recognise the same record, and what happens when the transfer fails.

Most failed integrations skip the third and fourth. Data moves happily for a month, then two customer records with slightly different spellings become four, or a network failure silently drops a day of orders and nobody notices until the accounts do not balance.

A connection is not a one-off task either. It is a small piece of infrastructure that needs monitoring, occasional repair when a vendor changes an API, and a documented description so the next person understands what it does.

The five connection methods

1. Native integrations

Many business tools include built-in connections to popular services. Your invoicing tool may already connect to your payment gateway; your online store may already push orders to your accounting package.

Use when: a native option exists and covers the fields you need. Advantages: no development cost, maintained by the vendor, usually the most reliable. Limitations: you get the vendor's field mapping, not yours; coverage is often partial. Cost: typically included, sometimes on a higher subscription tier.

Always check for a native connection before commissioning anything. Businesses regularly pay for custom work that duplicates a setting two clicks away.

2. Automation platforms

Tools such as Zapier, Make and n8n connect hundreds of applications without code, using triggers and actions you configure.

Use when: you need a connection between two common tools, volumes are moderate, and the logic is reasonably simple. Advantages: fast to build, changeable by a non-developer, good library of connectors. Limitations: priced per task or operation and usually in US dollars, so high volumes get expensive; complex logic becomes unwieldy; you depend on a third party staying available. Cost: subscription, plus ₦200,000–₦1,200,000 if someone builds and documents the flows for you.

Self-hosted options such as n8n suit Nigerian businesses with high volume or data-residency concerns, at the cost of hosting and maintenance.

3. Direct API integration

Custom code written against each system's API, running on your own server or inside your application.

Use when: logic is specific to your business, volume is high, or no connector exists. Advantages: full control, efficient at scale, no per-task fees, handles complex rules. Limitations: needs a developer to build and maintain; breaks if a vendor changes an API and nobody is watching. Cost: ₦150,000–₦1,200,000 per integration typically, more for complex or poorly documented systems.

4. Webhooks

A webhook is a notification one system sends to another the instant something happens — a payment succeeds, an order is created — rather than being asked repeatedly.

Use when: you need real-time reaction, particularly for payments and messaging. Advantages: immediate, efficient, the standard approach for payment confirmation. Limitations: you need an endpoint that is always reachable; you must handle retries and verify that the message genuinely came from the sender. Cost: usually part of an API integration.

Nigerian payment gateways including Paystack and Flutterwave provide webhooks for payment events. This is the correct mechanism for confirming payment automatically rather than having staff watch for alerts.

5. Scheduled file exchange

Data exported from one system and imported into another on a schedule, typically nightly, using CSV files or a shared folder.

Use when: one system is older, desktop-based or has no usable API. Common with entrenched accounting packages in Nigeria. Advantages: works with almost anything; simple to understand and audit. Limitations: not real-time; file format changes break it; needs a reconciliation check. Cost: ₦150,000–₦800,000 to set up reliably, including the reconciliation report.

Unfashionable but legitimate. A nightly export with a morning reconciliation report is far better than three people re-typing invoices.

How to choose the right method

The ordering matters: work down the list rather than starting with custom development. The cheapest connection that meets your reliability requirement is the right one, and you can always replace it later when volume justifies the change.

Step 1: Decide direction and trigger

Before any configuration, write one sentence per connection in this form: When (event) happens in (system A), (what data) should be created or updated in (system B).

Examples:

• When a payment succeeds at the gateway, mark the matching order paid in the order system and send a confirmation message.
• When an order is completed in the order system, create an invoice in the accounting package.
• When a new customer is created in the order system, add them to the messaging list if they consented.

Then decide direction explicitly. One-way is the default and should be preferred: one system owns the data, the other receives it. Two-way sync is occasionally necessary and considerably harder, because you must decide what happens when both sides change the same record. If you cannot state that rule clearly, do not build two-way.

Also decide the trigger type. Event-based fires immediately when something happens. Scheduled runs at a fixed time. Event-based suits payments and customer messaging; scheduled suits accounting postings and reporting extracts where a delay is harmless.

Step 2: Map the fields carefully

Write the field mapping as a table before building. This is where most silent data corruption originates.

Four traps worth naming:

• Currency units. Several payment APIs express amounts in kobo. A mapping that treats kobo as naira inflates every figure by a hundred. Confirm the unit in the provider's documentation.
• Phone formats. One system stores 0803..., another +23480.... Normalise at the boundary or matching fails and duplicates multiply.
• Field length limits. Long descriptions truncated without notice lose information nobody realises is gone.
• Required fields in the destination. If the destination demands a value the source does not have, decide the default now rather than letting the transfer fail every time.

Step 3: Handle duplicates and errors

Duplicate protection. Every transferred record needs a unique key the destination checks before creating anything. Use your order reference or a system ID, never a name or a timestamp. Without this, a retry after a timeout creates a second invoice for the same order — a common and expensive failure in Nigerian businesses reconciling payments.

Error handling. Decide in advance what happens when a transfer fails:

• Retry automatically, a limited number of times, with increasing delay
• Write the failure to a log with the record reference and the reason
• Add the record to a visible exceptions list, not just a log file
• Notify a named person when failures exceed a threshold
• Provide a manual way to reprocess a failed record once the cause is fixed
• Never silently discard a failed transfer

Exceptions list. The single most useful artefact in any integration. A simple screen or daily email listing what did not go through, with a reference and reason, checked by one named person each morning. Businesses that have this find problems in hours; businesses that rely on logs find them at month end.

Step 4: Test before you trust it

1. Test with real, messy data. Use actual customer names with unusual characters, orders with discounts, part payments and refunds — not three tidy sample records.
2. Test the failure path. Disconnect the network mid-transfer. Send a malformed record. Confirm nothing is lost or duplicated.
3. Test duplicates deliberately. Send the same record twice and confirm the destination rejects the second.
4. Check totals, not spot samples. Transfer a day's records and reconcile the count and the sum on both sides.
5. Test volume. Push several times your normal daily volume through and watch for rate limits or timeouts.
6. Run parallel for two weeks. Keep the manual process alongside the automated one and compare daily, exactly as with any switch-over.
7. Document what was tested, so the next developer knows what the connection is expected to handle.

Step 5: Monitor and maintain the connection

• Daily: check the exceptions list. Five minutes.
• Weekly: reconcile totals between the two systems for the week.
• Monthly: review automation platform task usage and cost, especially with dollar-priced subscriptions.
• Quarterly: confirm credentials and API keys have not expired, and check vendor notices for API changes.
• Annually: review whether each connection is still needed, and whether volume now justifies a different method.

Keep a one-page register of every connection: what it does, method, direction, trigger, owner, credentials location and last tested date. When something breaks eighteen months later, this page saves days.

The connections Nigerian businesses need most

Bank transfer matching deserves a note. Because so much Nigerian trade settles by direct transfer, many businesses use per-customer or per-order virtual account numbers offered by payment providers, which makes incoming transfers automatically identifiable. Discuss the options with your provider before building a manual matching process.

Example (hypothetical): a Lagos fitness studio

The following is a hypothetical illustration, not a Linestech client result.

A fitness studio in Lekki with 380 members uses a booking tool, a payment gateway, an accounting package and WhatsApp for member communication. The manager re-enters payments into accounting each week, checks the gateway dashboard against bank alerts, and sends class reminders manually.

Connection 1 (native, no cost). The booking tool already offers a native connection to the payment gateway. It had never been switched on. Two hours of configuration removed the need to check payment status manually.

Connection 2 (webhook, custom). A webhook from the gateway marks membership renewals paid and updates the member's expiry date automatically. Duplicate protection uses the gateway's transaction reference. Indicative cost ₦380,000.

Connection 3 (automation platform). New members created in the booking tool are added to the messaging list where consent was given, and a welcome sequence starts. Built on an automation platform in a day. Indicative cost ₦180,000 plus subscription.

Connection 4 (scheduled export). A nightly export of receipts to the accounting package, with a morning reconciliation report showing count and total on both sides. The package has no usable API, so file exchange was the right answer. Indicative cost ₦320,000.

Monitoring. A daily exceptions email lists failed webhook deliveries and rejected export rows. The manager checks it with the morning schedule.

Total indicative one-off ₦880,000, plus roughly ₦55,000 per month in subscriptions and support. The measurable change is that weekly manual re-entry disappears and membership expiry dates are correct without anyone maintaining them.

What connections cost

Indicative 2026 ranges for Nigerian businesses; actual costs vary with vendor, system documentation quality, volume and the exchange rate on subscriptions.

Budget a maintenance allowance. APIs change, credentials expire and vendors deprecate endpoints. A connection with no maintenance arrangement will eventually fail at an inconvenient moment.

Mistakes that break integrations

• Building custom work when a native option exists. Check the settings page first, every time.
• No unique key. Guarantees duplicates the first time a retry happens.
• Ignoring currency units. Kobo treated as naira produces figures a hundred times too large.
• Unnormalised phone numbers. The most common cause of duplicate customer records in Nigerian systems.
• Two-way sync without conflict rules. Both systems overwrite each other and data oscillates.
• No exceptions list. Failures accumulate invisibly until reconciliation exposes them.
• Credentials in a developer's personal account. When they leave, the connection dies and cannot be repaired.
• Testing only the happy path. The failure path is where money is lost.
• Per-task pricing at high volume. An automation platform that costs a little at 200 records a month costs a great deal at 20,000.
• No documentation. An undocumented connection is a future outage nobody can diagnose.

Conclusion

Connecting business software is mostly a sequence of unglamorous decisions done properly: check for a native integration first, use an automation platform when volumes are moderate, build direct API work when logic or scale demands it, use webhooks for anything that must happen immediately, and accept scheduled file exchange where older systems leave no alternative.

Then do the four things that separate a durable connection from a temporary one: map fields with the transformations written down, protect against duplicates with a unique key, route failures to a visible exceptions list somebody checks daily, and keep the credentials and documentation in your own organisation's hands.

If your team is still copying data between systems each morning, Linestech can review your current tools, identify which connections are native, which need building, and what each would cost — before any development begins.

Frequently asked questions

Do we need a developer to connect our software?

Not always. Native integrations and automation platforms are configurable by a capable non-technical person. You need a developer for custom API work, webhooks into your own systems, connections to older packages, or high-volume flows where per-task pricing becomes expensive.

Is Zapier or a similar platform worth the subscription in Nigeria?

For low to moderate volumes and common tools, often yes, because it removes development cost and is quick to change. The calculation shifts once you process thousands of records monthly, because per-task pricing in US dollars compounds. At that point a direct integration or a self-hosted platform usually costs less over a year.

What is the difference between an API and a webhook?

An API is the interface you call to ask a system for data or to send it something. A webhook is the reverse: the system calls you when an event happens. Use a webhook when you need to react immediately, such as confirming a payment, and an API when you need to fetch or push data on your own schedule.

How do we connect software that has no API?

Scheduled file exchange is the standard answer: export from one system, import to the other, reconcile daily. Some older packages also support database-level access or a vendor connector. Check what the vendor offers before assuming it cannot be done.

How do we stop duplicate records appearing?

Give every transferred record a unique key the destination checks before creating anything, and normalise identifiers — particularly phone numbers — at the boundary. These two measures prevent the large majority of duplicates.

Who should own the integration internally?

One named person who checks the exceptions list daily and holds the credentials register. They do not need to be technical. Integrations fail quietly, so the ownership matters more than the skill level.

How long does a typical connection take to build?

A native integration takes minutes to hours. An automation platform flow takes hours to a couple of days. A standard API integration takes one to three weeks including testing. Connections to poorly documented or older systems can take considerably longer, and should be scoped with a paid investigation first.

What happens when a vendor changes their API?

Well-built integrations fail visibly and stop rather than corrupting data. You then update the code against the new specification. Keeping a maintenance arrangement and watching vendor deprecation notices turns this from an emergency into scheduled work.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Paystack developer documentation
• Flutterwave developer documentation
• WhatsApp Business Platform — Meta for Developers