Skip to main content
A customer pays on the pay page. Helcim is the card processor behind that page: it takes the card or the bank details, and it posts the payment into QuickBooks itself. The engine records the payment the moment Helcim approves it, marks the invoice Paid or Partial, and then does the rest of the paperwork: the receipt, the Zoho payment, the paid work order. The live pay page is switched off for customers: the engine’s merchant record for the live environment has payments turned off, and only the demo one is on. Until the owner turns it on, no payment reaches the engine by any route, and the nightly invoice check reports every invoice whose QuickBooks balance disagrees with ours.

​
The shape of it

​
What follows a payment

A receipt goes out after every payment, including a part payment; it names the amount paid and the balance left. A bank transfer pays nothing until it clears, which takes days. Nothing follows while it is in progress. A step that fails after the money is taken is tried again, and dies as a dead letter if it keeps failing. The monitor raises that as an urgent condition in Sentry, because the customer has paid and the paperwork is unfinished. See Act on a Sentry email.

​
Edits and deletes in Zoho

The engine owns a payment’s amount and its method. A value typed over either in Zoho is refused: a human-review flag names the field, and the engine pushes its own value back. Deleting a Payment in Zoho changes nothing here or in QuickBooks; the engine writes nothing and raises a human-review flag, because the record is money that changed hands. See Resolve a human-review flag.

​
A payment recorded straight into QuickBooks

QuickBooks never calls the engine, and nothing here goes looking through QuickBooks for payments. A payment the office records there by hand reaches neither this side nor Zoho, and the nightly invoice check opens a condition when the balances disagree.