For repair shop software
Every repair ends at a card machine. Your software can supply it.
Synapto is the embedded payments partner for UK repair shop software. The ticket is yours. The estimate is yours. The collection reminder is yours. Then the customer taps a terminal that came from somewhere else, and that is where the money and the margin go.
How the money moves
The repair job your software already runs, from estimate to collection. Each stop is a payment your shops take today, by link or at the counter, through a provider each one chose separately. We move counter and online payments into your product: each shop is settled in full, and your margin is paid monthly.
The counter is the part nobody offered you.
Most software in this trade has solved the online half. A deposit on booking, a payment link with the estimate, a card page for a mail-in job. Fine as far as it goes, and usually running on a gateway the shop connected itself.
The larger half happens in the shop. Somebody hands over a watch, a phone, a guitar, a laptop, and pays for it standing at the counter. That volume never touches your product, because the terminal on the counter is not part of it. Two providers, two statements, and the shop reconciles the difference by hand.
The commercials
What counter payments can earn your platform
Most of your shops already take payment at the counter and by link, each through a provider the shop chose on its own. We move them onto payments inside your product, in your name and in planned groups of shops, and build the estimate, card machine and payout products that keep them there. Each shop is settled in full for every repair, and you receive your margin once a month.
Card machines through your platform, alongside the online payments you already handle. The shop gets one provider, one statement and one settlement covering both surfaces. You get a revenue line on the volume that used to be invisible to you, which in a counter trade is most of it.
- Your own subscription revenue on agreed terms
- A share of the in person volume, not just the online slice
- Card machines supplied, replaced and supported by us
- One settlement across the counter and the website
- Commercials in writing before you build anything
The rails
One integration, both sides of the shop.
The same API takes a deposit when the job is booked in, sends a link when the estimate is approved, and drives the terminal when the customer collects. For a shop with a service contract or an account customer, Direct Debit collects monthly on UK rails and lands on the same statement.
The deposit is worth taking seriously rather than treating as a nicety, because this trade's worst outcome is not a bad debt, it is a shelf. An item repaired and never collected cannot simply be sold on: the shop has to serve notice under the Torts (Interference with Goods) Act 1977 and wait, while the item sits there. A deposit at booking and a card held against the job is the only part of that a payments layer can actually improve, and it improves it a lot.
If a shop is small enough that a terminal is overkill, Tap to Pay turns the phone already in their pocket into the card machine, on the same account.
- Card machines and Tap to Pay on the same account
- Deposits and payment links from your existing flow
- Direct Debit for service contracts, on UK rails
- One statement, one settlement, one person to call
The weight
Onboarding small shops, done by us
This trade is micro businesses: one or two people, often a sole trader, frequently doing their own books. Onboarding several hundred of them is the part that quietly eats a platform team, which is why we do it rather than hand you a form to embed.
Their payment questions come to a named person here. Your support queue stays about software.
- Merchant boarding and verification handled by us
- Checks at onboarding, not months later
- An account manager your shops can phone
- Next day replacement if a terminal fails
From first call to first revenue
Book a payments review
Bring a rough idea of how many shops you have and what a typical job is worth. We show you what the counter is worth, in writing.
Scope the integration
Your team builds against our SDK, around your release schedule, with a payments engineer here for the payments questions. The terminal side included.
Board your shops
New shops payments-native from day one, existing ones moved when it suits them, all onboarded by us.
Earn on both surfaces
Online and across the counter, on one revenue line, with an account manager looking after both of you.
Questions
No. New shops can start on our terminals from the day they onboard, and existing ones move when their current arrangement suits them, usually at renewal. We look at their terms with them and say plainly whether moving now or waiting is the better call.
No. The terminal can run standalone against the same merchant account, so the shop gets one statement without you writing anything. If you want the amount pushed from your ticket to the terminal so staff never key it in, that is a small piece of work for your developer, and our engineer answers the payments questions while they do it.
Micro businesses and sole traders are normal here rather than an exception to be argued about. We do the checks at onboarding so nothing surfaces later, and we tell you up front if a shop is not going to pass rather than leaving them waiting.
It comes to us. The shop speaks to an account manager here who can see the payment and explain what is happening and what evidence helps. Your team stays out of it.
A thirty-minute payments review
Bring your shop count and a sense of the average job. We will tell you what the counter is worth and whether we are the right fit, including if we are not.