I get integrations that move money or data live, and keep them working after launch.

Integrations stall in predictable places, and it's rarely the technology. Sales said the API handles bulk refunds. It does, one at a time, and nobody checks until the customer's engineers hit it. Production credentials wait on someone who doesn't know they're the one holding things up. The provider's sandbox, which is their test environment, can't prove the one thing that breaks in production.

I stay with it from the sales handoff to real use. On day one I check everything the customer was promised and flag what I can't confirm. I work out who owns each dependency: you, your customer or a supplier. I keep what launch really needs apart from the nice-to-haves, so the extras don't push the date. At launch I watch the first live transactions all the way through and check the numbers match on both sides.

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.

A webhook is a message another system sends yours when something happens, like "payment completed". The calls themselves tend to work. The trouble is deciding which system gets the final say, and what happens when a step fails. Who decides a payment has settled: the customer landing on your thank-you page, the webhook, or your server asking the provider directly? What happens when the same event arrives twice, or the second one arrives first? What happens when your request to create a payment times out and you can't tell whether it went through?

In a review I follow each message through, step by step, and mark each part as fine, at risk or unknown, with the evidence next to it. I split what I find into what has to be fixed before launch and what can wait. Where it helps, I test your webhook endpoint directly by sending it duplicate, out-of-order, replayed, forged and tampered messages, and write down how it coped with each.

Docs drift. A spec promises validation the API doesn't do. An error comes back marked as a success, with the real message tucked inside. A field is documented in one unit and sent in another. Each of these is a production incident waiting for the right day.

I write tests that check each of these against the real API, usually in the provider's sandbox. Anything the docs promise gets a pass or a fail. Anything the docs don't cover gets recorded, and the next run tells you what's different. Alongside that I keep a copy of the provider's docs, API specs and SDK release notes under version control, and when something changes I trace it to the parts of your integration it touches.

Money flows have the usual integration problems plus a few of their own. Money arrives but never reaches the customer's balance. Goods ship because the customer saw a confirmation page, not because the payment settled. One side says complete while the other still says pending, and the chain disagrees with your ledger.

The fix is the same discipline as anywhere else. I decide with you which system has the final say, and write down how a payment is allowed to move from one status to the next. Then a late "pending" message can't overwrite a payment that's already settled, but a refund, a chargeback or a chain reorganisation still can, each through its own route. After that, I set up reconciliation, which means checking your records against the provider's and the chain's line by line, in a form your operations team can run without me.

Where regulation comes in, I show where it lands in the system. For example, a crypto withdrawal might be held until the sender and recipient details have reached the other provider, so I work out where that hold sits and what the customer sees while it waits. Interpreting the Travel Rule, MiCA and the rest stays with your legal or compliance owner.

Take preparing for a customer's technical call. Today it probably costs a senior person a morning of reading tickets and docs, because only they know what to look for. With a Claude Code skill, the agent reads the account notes, recent tickets and the current docs, then drafts a one-page brief. Each fact is marked as from the docs, seen in testing or inferred, so whoever takes the call can check it in minutes.

A skill is a set of written instructions for one task, kept with your code and reviewed like any other change. I write them for the work your senior people keep repeating. Each one says what it reads, what it checks and which file it updates.

The problem with agent output isn't that it's always wrong. It's that you can't tell which parts are wrong without doing the work again. Making every answer show where it came from fixes that. Rules about what must never leave the building are written into the skill and enforced by a script, not left to the agent's judgement, and a person signs off anything that matters.