One project · What it does · What it took
A recent project
A subscription service that takes monthly payments, and the systems behind it. One person built it, and one person keeps it running. Every figure on this page is measured, not estimated.
The client is not named here. Their site is public and recognisable, so that is their decision to make rather than mine.
What it is doing now
- 96%
- of the people who submitted the form went all the way through setting up the Direct Debit
- 1m 53s
- the middle time to sign up, from the first screen to the bank page
- 1,400+
- automatic tests run before any change reaches a customer
- 3 min
- from the site going offline to me being told, on the one night it happened
The job
What it had to do
Sign-ups arrived on a form. The form held the customer’s details and had no way of knowing whether a payment had ever been set up, so the two had to be matched by hand, and nobody could answer “has mine gone through?” without looking in two places.
What was needed was one place that knew both: who had signed up, and whether their Direct Debit was live. It had to take the money itself, keep the two sides in step without anybody watching, and be something one person could run.
Two minutes, three steps
What a customer sees
Three steps, on whatever screen they are holding. Everything they have typed is carried across to the bank page for them, so the only thing left to enter there is the bank details themselves.
Somebody who has already signed up is told so, rather than being allowed to start a second one and pay twice. Somebody who left halfway through is picked up where they stopped.
They are emailed at each stage after that: received, waiting on the bank, confirmed, and told if a payment fails. That is the part that stops the office answering “has it gone through yet?” by hand.
The half nobody sees
What runs behind it
One screen shows every sign-up and what state it is in, and the owner opens and closes sign-ups themselves, in windows set in advance.
New Direct Debits, cancellations and failed payments are applied from the payment provider’s own notifications as they arrive. Every six hours the site re-reads their event log for itself, so anything that never reached it is repaired rather than quietly lost.
How I know it is still working
Sixteen checks every morning
The database, the payment credentials, the scheduled jobs, the settings that would cost money if they were wrong. Each one reports on itself and the run fails loudly if any of them cannot answer.
Three more from outside
Round the clock, from somebody else’s servers. That is the difference that matters: a check running inside a site that has gone down cannot tell anybody it has gone down.
Over 1,400 automatic tests
They run before any change reaches a customer, and a change that breaks one of them does not go out.
It has been needed once. The outside checks caught the site going offline at 11:27 one night and told me at 11:30; the checkout was back at five past midnight. Nobody had used it for four hours, so no customer ever hit it. That is the whole of the argument for paying somebody to watch a thing you cannot see.
Taking money means taking care
What happens to people’s details
The assessment of what is held, why, and for how long was written before the site took its first payment, not after. There is a signed agreement covering the database, the email and the payments.
A sign-up that was started and never finished is deleted after 30 days, once the payment provider has confirmed it was never completed. Records are deleted twelve months after somebody cancels. Both of those happen on their own, because the version that depends on somebody remembering is the version that does not happen.