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. Each is authenticated differently because each is
trusted differently — the callback is signed rather than sessioned because it is the only
endpoint that can change a result.
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, and the callback returns to the URL it registered on the way in —
a closed loop a test 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.
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. What it replaces is
the state machine, not the signing.
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.