Surfboard Payments · 2022
Testing a payment SDK without shipping a terminal
TL;DR
- Problem
- Developers waited two to three weeks for a payment terminal before they could evaluate Surfboard’s SDK.
- What I did
- I designed a web and Android testing tool that let them run their first test payment the day they signed up.
- Key decision
- Keep the two-device model used by this payment setup: orders and responses on the web, the payment on Android.
- Outcome
- Developers could run a test payment without waiting for a shipped terminal. Demo costs fell by 80%.
- Same day
- Start SDK testing, previously a 2–3 week wait.
- 80%
- Lower demo costs.
- Team
- Design manager, 2 engineers
- My role
- Design, usability testing, dev handoff
- When
- Feb 2022 – Mar 2022
The problem
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.
Surfboard Payments provides terminals and a payment SDK for merchants and software platforms across Europe. This project focused on developers evaluating that SDK.
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.
Decision 1 of 3
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.
Decision 2 of 3
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.
1. Register. Download the Android app and pair it with the web tool using a six-digit code. 
2. Create an order. Create a test order on the web and inspect the payment request. 
3. Process and inspect. Complete the test on Android, then inspect its status and response on the web.
Decision 3 of 3
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.
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.