The Series· No. 32 · Act VIII — Running the Business

By DocuSeller · Published

The Money
DocuSeller · No. 32

Everyone gets paid, automatically

The money from a document sale never touches our bank account.

Not for a second.

It lands in the management company's own account, and our cut rides along on the same charge.

A management company delivery van carries a small platform-fee tag attached to the same charge The company’s chargeManagementcompanyPlatform feeTheir name. Their payout account.
Their company, their name, their payout account. The platform fee travels with the same charge.

Each management company is its own merchant of record. Own bank. Own payout schedule. Their name on the buyer's card statement, not ours.

Our platform fee is attached to that same charge, automatically.

No invoice. No second week of the month spent arguing about a spreadsheet called final_v3_USE_THIS.

Then there's the fee engine.

A fee is not a number hardcoded in the checkout. It's an audited record with:

→ a type — percentage, fixed, tiered, or a card-versus-bank surcharge
→ a frequency — once, every transaction, monthly, annual
→ a behavior — absorbed out of earnings, or added to the buyer's total

A three-part fee configuration shows type, frequency, and whether a charge is absorbed or added to the buyer total A fee has three configured dimensionsTypePercent or fixedTier / surchargeWhenOnce, per sale,monthly, annualWho paysAbsorb earningsor buyer pays
Three settings, one fee. Nothing here lives in the checkout code.
A future effective date changes new pricing while a prior receipt remains locked and unchanged Past receiptFuture start date→New pricing starts on its effective date
Tomorrow's price gets a start date. Last month's receipts stay exactly as printed.

Card processing costs real money, so each fee also carries a policy for who eats it: the company, us out of our own cut, or the buyer — through a total grossed up by a formula so the company still nets exactly what it expected to net.

And any company can override the standard pricing, with a start date.

Forward-dated, and on the record. Nobody retroactively rewrites last month's receipts.

Now the unglamorous part, which is most of the work.

In payments, all the interesting engineering is in the failure cases.

→ a misconfigured fee charges zero and writes a log line, instead of breaking a stranger's checkout at 11pm
→ messages from the payment processor are signature-checked and environment-scoped, so a test event can never move real money
→ a refund confirms it belongs to the right order before it does the irreversible thing
→ the ledger records our fee and the real processing fee off the settled transaction, once and only once, then reconciles what we charged against what actually landed

Three payment safeguards cover invalid fee configuration, processor event verification, and matching a refund to its order Checks before money movesFee configInvalid → $0Log the errorEvent checksVerify signatureTest / live scopeRefundMatch the orderThen refund
Three things that must never happen, each with something standing in front of it.

Nobody has ever thanked us for that last one.

They would notice its absence inside a week.

Next: the revenue chart most management companies have never once seen.

#Fintech · #PropTech · #SaaS