The payment tester that let non-engineers test payments
Every tool for testing a payment API assumes the person holding it writes code. That assumption quietly made integration a developer bottleneck. Removing it turned out to be worth more than any optimization of the developers.
The tools were fine. The audience was wrong
Testing transactions against the payment gateway meant one of two things. Either you used Postman, which requires understanding request bodies, headers, authentication tokens, and what a malformed payload looks like. Or you used the vendor's own developer sandbox, which is excellent documentation and equally unforgiving if you are not a developer.
The people who most needed to run a test transaction were often not developers. Account managers verifying a merchant's configuration. Support staff reproducing a failed payment. Merchants themselves, mid-integration, trying to work out whether the problem was on their side. Every one of those had to route the question through an engineer.
So the queue was not caused by the work being hard. It was caused by the tools requiring a specific skill to operate at all.
What we built
A payment tester with an actual interface. Vue.js on the front, PHP handling the calls to the gateway, Firebase holding configurations and saved test presets. I built it with a colleague on the team; the design work below was a joint effort.
The important part is what it does not ask you to know. Pick a scenario, fill in plain fields, press a button, and read a result written in a sentence rather than a JSON payload. The request that gets sent is exactly the one an engineer would have hand assembled in Postman. The person sending it no longer has to be an engineer.
Stack in this build
Vue.js
PHP
Firebase
Replaced Postman
The decision that made it worth more: white-labelling it
The tester began as an internal convenience. The judgment call was to build it so it could be branded and handed to a client rather than kept behind the company login.
That meant separating three things that are tempting to hard code: branding, credentials, and scenario presets. Once those are configuration rather than assumptions baked into the code, the same application serves an internal team, a merchant integrating for the first time, and a partner who wants it to look like their own tool.
The payoff was in integration speed. A merchant testing their own configuration, without booking time with anyone, moves through integration faster than one filing questions and waiting. The white-label decision cost perhaps a fortnight of extra design and turned an internal tool into something the business could put in front of clients.
It went further than expected. The gateway vendor adopted the tester as its own reference documentation, which is an unusual outcome for an internal utility and the strongest signal I have that the audience problem was real and not just ours.
What I would do differently
The tester made testing accessible and did not make results interpretable. A failed transaction still returns a gateway response code, and knowing that a particular code means an address mismatch rather than a declined card is its own expertise. Mapping the common failure codes to plain explanations, with the obvious next action, would have removed the second bottleneck the same way we removed the first.
The lesson generalises past payments. When a tool is only usable by specialists, the constraint is rarely the task. It is the interface, and interfaces are cheaper to fix than people are to hire.
What changed
Integration conversations stopped queuing behind engineering, merchants could self-serve their own configuration checks, and the gateway vendor adopted the tool as reference documentation. It is still in use today.
Have a system only your specialists can operate? Get in touch.