Case study · Working softwareL1–L5 · Full stack of the framework

UAT-Ops

A workbench for the part of a payment integration that usually goes badly: UAT and onboarding. You point it at a provider’s API and it builds a tested catalog with working auth, exercises it against the real sandbox, and produces the documents an engagement actually needs. There’s an AI layer that can run the whole cycle on its own, inside limits you set.

Role: Designer and sole builder
Period: Apr 2026 – present
Type: Working software · not open yet

The problem

Payment integrations don’t usually fail in development — they fail in the last mile. UAT and onboarding is where vendor documentation meets reality: credentials that don’t verify, endpoints that behave differently than documented, edge cases nobody exercised, and engagement knowledge that lives in one engineer’s head. Most teams run this phase on Postman tabs, spreadsheets, and memory.

I got tired of rebuilding that process by hand for every engagement, so I built it once. Every call it makes is a real call, and it keeps the response, so questions about whether an integration works have an answer you can go and look at.

See it running

No cuts and no narration. Partway through, a 13-case UAT suite runs against the sandbox, so the coverage bar and the checkmarks are a real run happening as you watch. The log screen straight after shows those same calls arriving, timestamped “just now.” Recorded against a demo tenant, so none of the data on screen belongs to a real customer.

What's actually in it

Payment gateways in sandbox

1,262

Endpoints in the catalog

5,800+

Logged sandbox executions

Onboarding runs

5,400+

Tests in the green suite

Data models

Metrics verified · 28 Sep 2026. Counted from the live database and test suite, current sandboxes only.

The core cycle

1
Ingest — Import a Postman collection, OpenAPI spec, or docs site — preview first, then confirm.
2
Providers & endpoints — A managed catalog with inferred auth configuration.
3
Credentials — Entered write-only, verified against the live sandbox with a four-phase proof.
4
Flows — Endpoints composed into sequential flows with variable chaining, run server-side.
5
Issues — 4xx/5xx responses auto-create tracked issues.
6
UAT campaigns — Suites, cases, and runs with durable history and a per-endpoint assessment ledger.
7
Documentation — AI-generated runbooks and API references, plus deterministic deliverables and Postman exports.

Rules I don't bend

No fake calls

Every provider interaction goes through a real server-side executor against the real sandbox. No mocks, no fabricated responses, anywhere.

Tenant isolation is absolute

Schema-per-tenant in Postgres. No cross-tenant reads, writes, or authority — platform admins cannot touch tenant business data.

AI acts only inside a delegated envelope

Autonomy is per-tenant, opt-in, bounded by operation class and provider allowlist, interruptible, and audited through a single gate.

Evidence over inference

Verification states and documentation claims are measured against live behavior, not assumed from reading code.

Where it sits in the framework

Most projects touch one or two layers. This one ended up touching all five, which is part of why I keep pointing at it:

L1 · OperationsOnboarding runs the same way every time, with the handoffs written down, instead of being improvised per engagement.

L2 · InfrastructureCredentials, catalogs, execution history and audit trails live in one place rather than across spreadsheets, Postman, and whoever happens to remember.

L3 · ClarityEvery endpoint carries a verification state backed by an actual call, so “does this work?” stops being a matter of opinion.

L4 · DeliveryRunbooks and API references are generated from what the API actually did, which is why clients can build from them.

L5 · SignalFailures turn into tracked issues during UAT, while they are still cheap, rather than arriving later as a customer complaint.

Honest state

This isn’t a product yet. One operator uses it today — me — though it’s built multi-tenant underneath, and opening it up on proper hosting is the plan. The walkthrough runs against a demo tenant; the numbers come from the real one.

The part anyone can use today is the payment integration directory: which gateways connect to which commerce platforms, how, and what goes wrong, with every claim sourced and dated. Where I’ve run a gateway’s sandbox through UAT-Ops, the redacted evidence from that run is on the gateway’s page.

If this is the phase your own integration is stuck in, payment integration design is the engagement built around it.

Where to next

Payment integration design Experience Résumé