For integrations that move money or data, and the teams that have to run them.

Integrations stall in predictable places. A capability promised in the deal that nobody checked against the docs. A dependency with no name next to it. A test environment that could not prove the one thing that breaks in production. The technology is usually fine.

I stay with it from handoff to adoption. On day one, every promise gets verified or flagged. Dependencies are split by owner: yours, your customer's or a third party's. Launch requirements sit on a separate list from nice-to-haves, so the date holds. At launch I watch the first transactions end to end and reconcile them.

Live is not the finish line. A launch nobody uses is not a success, however clean the go-live was, so I give the first month of real traffic the same attention as the build.

The calls themselves tend to work. The trouble is in who owns which state, which system has the final say, and what happens when a step fails. Who decides a payment has settled: the browser redirect, the webhook, or a server-side read of the provider's own record? What happens when the same event arrives twice, or the second one arrives first? What happens when your call to create a payment times out and you cannot tell whether it went through?

In a review I walk the flow end to end as a numbered sequence, then mark each area as fine, at risk or unknown, with the evidence next to it. Findings are split into launch blockers and later improvements. Where it helps, I put the webhook endpoint under test directly: duplicate, reordered, replayed, forged and altered deliveries, each with a note on how the endpoint responded.

Docs drift. A spec promises validation the API does not do. Errors come back inside an HTTP 200. A field is documented in one unit and sent in another. Retries stop after a window nobody wrote down. Each of these is a production incident waiting for the right day.

I build a harness that turns those questions into checks. Documented behaviour gets a pass or fail. Behaviour nobody promised gets recorded and compared on the next run, so the useful output is what changed. Alongside it, I mirror, snapshot and diff the vendor's docs, API specs and SDK release notes, and trace each change to the parts of your integration it touches.

Money flows carry the usual integration problems plus a few of their own. Funds that moved but were never credited. Goods released on a browser callback instead of a settled event. A payment marked complete on one side and still pending on the other. The gap between what the chain says and what your ledger says.

The discipline is the same as anywhere else. Decide what is authoritative and write the allowed transitions down, so a late status update cannot overwrite a settled payment, but a refund, a chargeback or a chain reorganisation still can, each through its own path. Then make reconciliation something an operations team can run.

Where regulation comes into it, I show where it lands in the system: a withdrawal held until the originator and beneficiary data reaches the other provider, and what the user is shown while it waits. Interpreting the Travel Rule, MiCA and the rest stays with the people who own it.

Most teams using AI assistants have found a faster way to write the same first draft. The bigger win is encoding the process itself: what to read before a customer call, which facts to check against current docs, where a decision gets recorded, and what counts as ready to launch.

I turn that into a set of skills and workflows that live in your repo. Each one says what it reads, what it checks and which file it updates. Every claim it produces is labelled documented, observed or inferred, with the source beside it, so a person can check the output instead of redoing it.

This site runs the same way. A skill drafts its copy updates, a check script blocks company names, people and personal details, and nothing deploys until I have read the diff.