opsira

Automating orders, payments and returns

Overview

The unglamorous half of an automated business: matching money to records, references humans can read, and getting your hardware back.

Taking the order is the part everyone builds. The money leaks afterwards, in the joins: matching a payment to the record it belongs to, knowing what came back, and chasing what did not.

Every inbound event needs to carry its own join key. A payment link that collects nothing but money cannot be matched to anything. Reconstructing the link from incidental details like an email address works in testing, because in testing the same person always uses the same details. In production people pay from a different address, with a partner''s card, from an old billing address, and your automation silently fails to connect the two.

When matching fails, that is an exception, not information. Money that arrives and cannot be attributed should shout, with everything a human needs to resolve it in the message. Ours reported it politely at normal priority and was scrolled past, and a paying customer stayed on course to be chased as an overdue non-return.

References are an interface. They get read over the phone, typed into a payment description and quoted in complaints. Optimise them for the human repeating them back to you, not for the database.

Returns are the part rental businesses underestimate. Build the loop around the carrier scan rather than the parcel arriving: it happens days earlier, it is verifiable, and it is the event that should stop the chasing and release the refund.

The 6 notes in this area

Matching bank transfers to orders automatically

When card payments are not available, bank transfer works, but only if reconciliation is automatic. Polling, matching, and the tolerances that matter.

Payment links need an order identifier

A hosted payment link that collects nothing but money cannot be matched to the record it belongs to. What that costs, and the field that prevents it.

Returns operations that mostly run themselves

Return labels, scan detection, chasing what has not come back, and tying refunds to a scan rather than a promise.

Automatic review invitations, without breaking the rules

Getting reviews consistently by attaching the invitation to an event you already have, and the compliance line not to cross.

Sequential order numbers, and why random ones cost you

Random reference numbers seem safer and create work at every point where a human has to read one back to you.

Validation rules that fire on correct data

A guard that rejects one document in eleven because reality disagrees with it is worse than no guard at all. Test every rule against real history before it goes live.

Need help with any of this?

These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.

Other guides