An Integration Starts Being Work After the First Call Succeeds

The Screen Where One Call Worked

Integration requests usually arrive as a list of names. Payments, maps, messaging, sign-in. The names suggest similar amounts of work, and then the quotes come back different.

For a developer the first success is quick. Paste the example from the docs, get a test key, watch a response come back. When a payment sheet opens and an approval message appears on screen, it is fair to say the thing is connected.

That screen is one case, though, and it is the case that went well. Once the product is live, the cases that do not go well arrive daily. Scoping an integration means counting those cases, and that count is where quotes separate.

Accounts and Approvals Set the Calendar First

Plenty of external services cannot be opened by a developer alone. Someone applies as the business, submits documents, and waits for review before a production key exists. Anything touching money, identity, or outbound messaging usually carries that process.

None of that time sits inside the development schedule. However fast the code gets written, nothing can be verified against a real account until approval lands, and approval sometimes depends on your own screens or policy text being ready. A rejection resets the wait by however long the fix takes.

Which makes the first question on an integration quote a question about who applies. Handing over account setup and review correspondence produces a different timeline than keeping it in-house and outsourcing only the build.

What Passes in Sandbox and Stops in Production

Most providers hand out a test environment. Any card number gets approved, messages never actually send, and development runs comfortably inside it.

Production attaches conditions. Some providers require the calling domain or server address to be registered in advance. Some require the address that receives results to be publicly reachable and properly certified. Some check that a settlement account or a sender identity matches what was registered, and reject anything that does not.

None of that is a coding problem. It is a supplies problem, and missing supplies stop a launch after the code is already done. Asking for the go-live requirements at kickoff rather than at the end is what shortens this stretch.

Failures, Duplicates, and Cancellations

There is one success path. There are several failure paths, and most of the work in an integration lives on those.

The classic one is a request that times out while waiting. Your side records a failure while the provider’s side has finished processing. The user assumes nothing happened and presses again, so the same request lands twice. This is where you need a way to accept the same request twice and act on it once, plus a screen that compares both sets of records.

Cancellation and refunds are their own flow. A full reversal behaves differently from a partial one, and once funds have settled on the provider’s side the procedure changes again. Result notifications frequently arrive more than once, so the same notification has to be safe to receive repeatedly.

How far to build those flows is the real content of an integration scope. Sending the list of services along with an answer to “what happens when a customer cancels” gets you a far more accurate quote.

The Day the Provider Changes the Spec

An integration can break while your code sits untouched. Providers retire old versions, drop fields that used to be in the response, and change how authentication works. Notice goes out ahead of time, and it goes to whoever created the account.

So an integration behaves less like a finished item and more like something under watch. At minimum, route provider announcements to an address somebody actually reads, and keep a single page listing every external service you depend on and whose name each account sits under. That page pays for itself later.

Send Us the List of Services and We Can Start

At Weple an integration request gets turned into a question about cases before it becomes a question about services. Who applies for the accounts, what the provider demands before going live, how far the cancellation and duplicate handling should go. Once those are written down separately the scope is visible. What we charge against is set out on the pricing page. If working through it shows that a given service is not worth connecting yet, we will look for the way around it with you.