These are rebuilds of work I did at a company, published so the approach can be read.
The architecture, the decisions and the operational habits travelled; the employer's
code, business domain and branding did not.
A dashboard and the test suite it dispatches are one system; the payment sandbox
stands alone. Both are drawn below.
SYSTEM ONE
Dashboard and test suite
Two repositories with no shared code, meeting at four points. One run, end to end.
Blue marks the four boundary crossings, and each is authenticated differently because each
is trusted differently. The run row is written before GitHub is called, so a run that fails
to dispatch still appears with its error rather than vanishing. The callback is signed
rather than sessioned because it is the only endpoint that can change a result. The report
goes straight into the bucket with a token scoped to it, rather than through the Worker —
an endpoint accepting several megabytes would need a body limit, a parser and a signing
scheme over something too big to buffer, all to reach a bucket the job can already write to.
Standalone. Your backend talks to it exactly as it would to the real provider, the
callback comes back to your backend, and you drive what that callback says from the side.
The backend is unchanged: it calls a payment API and gets the provider's own response
shape back. The callback then returns to that same system — the URL it passed as
backendReturnUrl on the way in — which is what makes this a closed loop you can
assert on. What the sandbox adds is the second door, where a test decides what comes back,
including the cases a real staging environment will not produce on demand. If the webhook
does not exist yet, the built-in inspector takes its place and holds what arrived.
One deliberate limit: 2C2P wraps production payloads in JWT/JWE, and this sandbox speaks
plain JSON, so an integration points at it with encryption disabled in test config. The
signing step needs its own test against the real sandbox; what this replaces is the state
machine around it.
Self-service test running: a developer picks a slice, presses Run, and gets a link to
the report, without waiting for QA or digging through CI artifacts.
The interesting part is not the Run button, it is who may run what and who may then see
the result. Four roles get four different dashboards, and demo can never
trigger a real run, which is what makes its password safe to publish.
The same API suite built twice, so the approaches can be read side by side: one
functional, one class-first. 97 tests each, verified by mutating the mock and checking
that both suites fail identically.
The finding worth taking away: removing the status-code check from the shared assertion
helper left every test passing in both packages. That is a property of centralising
assertions, not of either style.
This is the suite the dashboard dispatches. It covers the API today; UI tests are the
intended next layer and are not written yet, and the dashboard dispatches by scope, so
they arrive without a change on either side.
03Paygate SandboxLIVE
A sandbox that emulates the 2C2P and Omise payment APIs, so an integration can be tested
against responses a real staging environment will not produce on demand.
Settle a transaction, decline it with a specific issuer code, make an inquiry time out,
or deliver the same webhook twice out of order. A built-in callback inspector captures
what the webhook would have received. Unofficial, and not affiliated with either provider.
Each repository carries a provenance.md stating what travelled from the
original work and what did not, and how AI was used in the rebuild. Depth without
explanation invites the wrong question, so the explanation is written down.