Testing a payment SDK without shipping a terminal
Developers waited two to three weeks for a payment terminal before they could evaluate Surfboard’s SDK. I designed a web and Android testing tool that let them run their first test payment the day they signed up.
- Lower demo costs.
- 80%
- Start SDK testing, previously a 2–3 week wait.
- Same day
Context
Surfboard Payments provides terminals and a payment SDK for merchants and software platforms across Europe. This project focused on developers evaluating that SDK.
The problem
A hardware dependency before the first test
Every evaluation depended on a shipped terminal. The delay added cost and gave prospective customers time to lose momentum before they had tried the product.
What the tool needed to prove
Developers needed to create an order, complete a test payment and inspect the API response. A walkthrough alone could not replace that hands-on evaluation.
The goal was to make that workflow available in software, without a dedicated terminal to ship, track or recover.
My role
I owned the flow and interface design through handoff. I worked with engineering on the API information to expose, and with sales on what developers needed to judge the SDK.
Key design decisions
Keep the two-device workflow
I considered a single-screen tool, then kept the two-device model used by this payment setup. Developers create orders and inspect responses on the web. The Android app handles the payment interaction, with both surfaces updating together.
Get to the first payment sooner
Early versions asked for too much setup before showing a working payment. I reduced order creation to the essential inputs so developers could try the core flow before exploring more scenarios.
Make the result useful for debugging
I showed status codes, response fields and failure states alongside the payment result. Developers could inspect what the API returned and use that information while building their integration.
The flow
Register
Download the Android app and pair it with the web tool using a six-digit code.
Create an order
Create a test order on the web and inspect the payment request.
Process and inspect
Complete the test on Android, then inspect its status and response on the web.
Outcome
Developers could run a test payment using the web tool and Android app without waiting for a shipped terminal. Demo costs fell by 80%.
What I learned
The useful simplification was removing the hardware dependency while keeping the payment model familiar. I would bring more failure-response examples into the first evaluation flow so developers can judge recovery as well as success.