API Integration: What Breaks, Why, and How to Budget for It

Part of our guide hub: Custom software development

Integrations are the most commonly underestimated line in every software quote. On paper, connecting to a courier or a payment gateway looks like a small piece of work: call their endpoint, read the response. In practice it is the part of the project most likely to slip, and the part most likely to break eight months after launch.

Here is why, and what to do about it.

Why an integration is not just a function call

Writing the code that calls an external service is perhaps twenty percent of the work. The other eighty percent is everything around it:

• Authentication and credential management, including what happens when a token expires at 3am.
• Mapping their data model to yours. Their “order status” has nine values; yours has four. Someone has to decide the mapping and what happens to the five that do not fit.
• Failure handling. What the system does when the service is down, slow, or returns something unexpected.
• Retries without duplicates. Retrying a failed payment request is how customers get charged twice.
• Testing against a sandbox that behaves differently from production, which they always do.
• Monitoring, so you find out it broke before your customers tell you.

The six failure modes that appear in month three

1. The timeout that is not a failure

Your request to a payment gateway times out. Did the payment go through? You do not know. If you treat it as failed and let the customer retry, you may charge them twice. If you treat it as successful, you may ship goods nobody paid for.

The correct handling is an idempotency key and a reconciliation process. This is not optional for anything involving money, and it is frequently missing from cheaper quotes.

2. Rate limits under load

Everything works in testing with ten requests. On the first sale day you send four thousand and the service starts rejecting them. Handling this requires queuing and backoff, which is architecture rather than a fix.

3. Silent schema changes

The provider adds a field, renames one, or changes a value from a number to a string. Your integration stops working and nobody is notified. This is the most common cause of “it worked yesterday” incidents.

4. Sandbox and production divergence

Sandbox environments are simplified. They respond faster, never fail, and often skip validation that production enforces. Every integration needs a real transaction in production before launch, and budget for the surprises that surfaces.

5. Partial success

You create an order in your system, then push it to the courier, and that second call fails. Now your records and reality disagree. Every multi step integration needs a defined answer for this, usually a queue with retry and a way to see what is stuck.

6. Credential expiry

API keys rotate, certificates expire, merchant accounts get suspended for unrelated reasons. Without monitoring, the first sign is a customer complaint.

How to budget realistically

As a rough guide for a business system:

• A simple, well documented REST API with a good sandbox: 3 to 6 days of work.
• A payment gateway: 5 to 12 days of engineering, plus three to six weeks of calendar time for merchant onboarding, which runs in parallel and is outside anyone’s control.
• A courier or logistics API: 5 to 10 days, more if it involves label generation or tracking webhooks.
• An older enterprise system with SOAP or a file drop: 10 to 25 days, and expect surprises.
• An undocumented API, or one you have to reverse engineer: do not fix price this.

The pattern that matters: two integrations is a footnote in a project. Six is a project inside the project. Count them before you agree a timeline. Our breakdowns of website costs and app costs both identify integration count as a primary cost driver for the same reason.

Questions to ask before signing

1. Is there real documentation and a working sandbox? If not, add fifty percent to any estimate.
2. Who owns the account relationship? Someone at your company has to be able to call them when it breaks.
3. What is the rate limit, and what is our expected peak?
4. How are we notified of changes? Is there a changelog or a developer mailing list?
5. What is the support arrangement when their service fails? For local Pakistani providers this varies enormously and is worth checking before you depend on them.
6. Is there a webhook, or do we have to poll? Webhooks are cheaper to run and require a publicly reachable endpoint, which affects hosting.

What good integration work looks like

• Every external call is logged with its request, response and timing.
• Failures go into a queue with retry, not into the void.
• There is a screen where someone non technical can see what is stuck and retry it.
• Monitoring alerts a person when the failure rate crosses a threshold.
• Credentials live in configuration, not in code, and rotating them does not require a deployment.

If a quote has no line for any of this, the integration is being priced as the twenty percent rather than the whole thing.

Start them in week one

The single cheapest thing you can do to protect an integration heavy timeline: begin every commercial onboarding process on the first day of the project, before the code that needs it exists. Merchant accounts, sender IDs, API access requests and compliance paperwork all sit in someone else’s queue, and the engineering waiting on them is usually the smaller half.

Frequently asked questions

Why do integrations cost so much?

Because the code that makes the call is a small part of it. Failure handling, retries, reconciliation, testing and monitoring are the majority of the work and the reason the integration still works next year.

How long does a payment gateway integration take in Pakistan?

Five to twelve days of engineering, but three to six weeks of elapsed time is normal once merchant onboarding and sandbox approval are counted.

Can we add integrations later?

Yes, and it is usually the right decision. Launch with the one integration that proves the business works, then add others against demand rather than speculation.

What happens if the provider changes their API?

Your integration breaks unless someone is monitoring it. This is why a maintenance arrangement matters for any system that depends on external services.

Ezitech builds integrations with payment gateways, couriers, ERPs, POS systems and government portals across 10 or more industries. Tell us what needs to talk to what.