This is the last part of the series. You have chosen a conversion model, trimmed the form, matched the tool to the scale, picked a payment method and put honest pricing and trust signals on the screen. What remains is everything after the money arrives.
Many sites stop here, with a single confirmation screen. For the customer, though, this is the beginning. They have paid, and now they want to know what happens.
The five minutes after payment decide the trust
The moments straight after payment are emotionally the least settled part of the whole journey: money has left, nothing has arrived. Silence in that gap grows into “is this actually a real business?”, and it is where support enquiries cluster.
The fix is not difficult: say in advance what is going to happen. Three automated emails handle almost all of it.
The three emails that must send themselves
One — order received. Sent the instant an application lands. It carries the order reference, a summary of what was requested, what to do next (for a bank transfer, the account details and the name to use), and when the next message will arrive. Without it the customer cannot tell whether the submission worked.
Two — payment confirmed. Sent when the transfer or card payment clears. The important content is not the amount but what happens from here. If you need something from the customer — files, access, a date to confirm — this is the message that asks for it.
Three — completion. Sent with the result: what was done, what to check, and where to ask questions afterwards.
All three should be templated and sent automatically. Written by hand, they get skipped on busy days — and the customer who was skipped is the most anxious one you have. Do check that these messages actually arrive, too; a shaky sending path makes the whole automation pointless.
Keep the state as a record
You need to see which stage every order is at, on one screen. Held in your head or scattered through an inbox, it collapses the moment volume rises.
The real reason to keep states is spotting the stuck ones. An order sitting at “paid” for several days means either the customer has not sent what you asked for or you forgot to ask. Either way, the list shows it immediately.
Handover and closing
Finally, make a list of what has to be handed over: the deliverable, how to verify it, any accounts and access involved, and the receipt or tax invoice. Business-to-business customers will ask for documentation without fail, so publishing where to request it removes an entire round of email.
The refund route belongs to this stage as well. Each payment method unwinds differently, so follow the procedure you already wrote into your refund policy — this is the moment that earlier work pays off.
Closing the series
Eight parts, in short: decide how your deals close, buy the smallest tool that supports that, write price and conditions honestly, and prepare the flow that follows payment. Revenue comes from completing the flow, not from adding tools.
Once this is in place, attention usually turns to speed and stability. The work that is genuinely hard to do alone — version upgrades, performance work, security review — is handled as one job by our optimization program, and the order we measure and fix in is published on the process page. Articles on operational automation keep accumulating in the development workflow archive.