A customer places an order through a website. The payment is accepted, but the order never reaches the fulfilment system.
Nothing crashes. No error appears on the office computer. The customer receives a confirmation, while staff continue working from a queue that is missing the transaction. The problem may only become visible when the customer calls to ask where the order is.
This type of failure is common in small businesses that connect online stores, payment platforms, booking systems, accounting software or delivery tools. The systems may each be working correctly, but the connection between them can fail without giving the business a useful warning.
The operational question is not simply, “Can these systems integrate?” It is:
What should happen when an important transaction cannot move from one system to another?
A successful API call is not the same as a successful business process
An API is a controlled way for one software system to exchange information with another. For example, an ecommerce website may send a new order to an inventory or accounting platform.
A technical response can look successful even when the wider process is not complete. A request might time out after the receiving system has partly processed it. A record might be rejected because a product code is missing. An authentication token might expire. A service may be temporarily unavailable.
There can also be failures caused by valid but unexpected data:
- A customer record is missing a required field.
- An item has been discontinued but is still available online.
- A tax or delivery value does not match the receiving system’s rules.
- A duplicate request creates uncertainty about which record is correct.
- A connected service changes its API behaviour.
If the integration only records a technical error in a developer log, the business may not know that an operational task has been interrupted.
The hidden cost of silent failure
For an SME, a missed integration event can create several kinds of work:
- Staff manually compare records across systems.
- Customers contact the business for updates.
- Orders or bookings are entered again.
- Inventory information becomes unreliable.
- Invoices or receipts are delayed.
- Staff spend time deciding whether a transaction was completed.
- A small backlog grows before anyone notices it.
The cost is not limited to the failed API call. It includes investigation, correction, customer communication and the risk of making the wrong correction.
A good design therefore treats integration reliability as an operational process, not only a programming task.
Design the failure path before the connection
Before building or changing an integration, map the business event from beginning to end.
For an online order, that might be:
- The customer submits the order.
- Payment is authorised.
- The order is stored in the online system.
- The fulfilment system receives the order.
- Stock is checked or reserved.
- The customer receives the appropriate update.
- Finance receives the information required for reconciliation.
Each step should have a clear outcome. If step four fails, the design should answer:
- Is the transaction saved for another attempt?
- How many times should the system retry?
- How long should it wait between attempts?
- How will a permanent data error be separated from a temporary outage?
- Who is notified?
- Where can staff see what happened?
- How can the process be safely resumed?
This prevents the common mistake of designing only the “everything worked” path.
Use retries carefully
Temporary failures can often be handled automatically. A receiving service may be unavailable for a short period, or a network request may time out.
A retry mechanism can attempt the operation again after a delay. The delay should generally increase between attempts rather than sending repeated requests immediately. This reduces pressure on a service that may already be recovering.
Retries need limits. An integration should not keep attempting the same failed transaction indefinitely. After a defined number of attempts, the event can be placed into an exception queue for review.
The system must also consider duplicate processing. If an order was accepted but the response was lost, sending it again could create a duplicate order. Where possible, integrations should use an idempotency key or another unique reference so the receiving system can recognise that the event has already been processed.
In business terms, this means the system can safely ask, “Have I already handled this transaction?” before creating another record.
Make exceptions visible to the right person
An alert is useful only if someone can understand and act on it.
A practical support view might show:
- The transaction reference.
- The time the event was created.
- The systems involved.
- The number of retry attempts.
- The latest error category.
- Whether the issue is likely temporary or requires data correction.
- The next recommended action.
Not every technical event needs to interrupt a business owner. A short outage may resolve through automatic retries. A failed customer order, however, may need a prompt operational alert.
Notifications should be directed according to responsibility. An office manager might handle missing customer information, while a technical support contact may investigate authentication or service availability.
Monitor business outcomes, not just system uptime
A website can be online while orders are not reaching fulfilment. An accounting platform can be available while invoices are not being created.
Monitoring should therefore include business signals such as:
- Orders waiting longer than expected.
- Bookings without corresponding confirmation records.
- Payments without matched invoices.
- A growing number of failed or pending events.
- No successful synchronisations during a period when activity is expected.
These checks provide a more useful picture than a simple “system is up” message.
For an SME, monitoring does not need to begin with a complex enterprise platform. A structured integration log, exception queue, scheduled health check and practical alerting process may be enough to make failures visible and manageable.
Build support into the integration
Reliable integrations need maintenance. Credentials expire, APIs change, data rules evolve and business processes are adjusted.
A supportable implementation should include:
- Clear ownership of each connected system.
- Documented failure categories.
- A runbook for common exceptions.
- Safe replay or reprocessing controls.
- Logs that protect sensitive information.
- Testing for expected and unexpected responses.
- Alerts that can be reviewed without reading technical code.
The goal is not to eliminate every failure. That is unrealistic. The goal is to ensure failures are detected early, contained safely and resolved without guesswork.
The practical lesson
An integration is not complete when two systems can exchange data. It is complete when the business knows what happened when the exchange succeeds, fails, is delayed or produces an uncertain result.
For Australian SMEs, a modest investment in retries, exception handling, monitoring and support documentation can prevent a technical issue from becoming a customer-service problem or a reconciliation exercise.
Melbourne Digital Solutions can help businesses assess critical system connections, design safer failure paths and implement integrations that are easier to monitor and support. The right starting point is usually a review of the business events that must never disappear silently.
