Quotes and doorstep payments in a field app

What do quotes and doorstep payments cover?

The gap most field operations lose money in is between finishing the work and getting paid for it. Paper quotes get lost, invoices get raised late, and cash rides home in the van. Closing that gap on site is the point of this capability.

• A guided quote wizard. The engineer walks through options, quantities, and add-ons, and the app produces a clear price in front of the customer. Pricing rules live on the platform, so the figure is consistent whoever is quoting and wherever they are.
• On-the-spot approval and terms. The customer approves the quote and accepts terms in the same flow, captured against the job with a timestamp, rather than waiting on a follow-up email that may never be actioned.
• Deposit and balance. A job can take a deposit at the door and schedule the balance, using the Billing Engine’s charge, instalment, and advance-payment handling so each part is tracked to completion.
• Card-present and online payment. We integrate a card-present provider for a tap or chip payment on the phone or a paired reader, with settlement, invoices, and receipts running through the proven Billing Engine.
• Refunds with guardrails. Full or partial refunds are initiated from the job with the same over-refund protection proven in the Billing Engine, so a doorstep refund can never exceed what was paid.

How it behaves at the edges

Payments are where a field app has to be exactly right, because the failure modes cost money and trust directly. These are the cases we design for explicitly.

• Payment succeeds but sync fails. The provider confirms the payment and the app records it locally with an idempotency key. On reconnect the record reconciles once; a retried sync returns the existing result rather than a second charge. This is the guarded, idempotent transition proven across the Billing Engine.
• Quote approved offline, then a price changes centrally. The approved quote is captured as an agreed figure against the job, so a later central price change does not silently rewrite what the customer agreed to at the door.
• A partial payment on a poor connection. A deposit taken offline queues like any other action and settles on reconnect, with the outstanding balance scheduled and visible to the office throughout.
• A refund on a job that has not finished syncing. Refunds validate against the settled payment record, so a refund cannot be issued against money the platform has not yet confirmed was taken.

Integration points

Doorstep payments lean almost entirely on capabilities that already run in production.

• Payments, invoices, and refunds come from the Billing Engine, including its event-sourced financial audit trail.
• Financial attribution to the right franchisee and territory is handled by the Franchising module, so a payment taken at the door lands against the correct part of the network.
• Receipts and confirmations can be delivered by the same push and deep-link layer that drives the rest of the app.

Why it matters

Getting paid on site removes an entire back-office process and the leakage that goes with it. The engineering that makes it safe, idempotent payments, guarded refunds, and an audit trail on every transaction, is not new work: it is the Billing Engine, put in the hand of the person at the door. The companion guide below covers how to evaluate this against your current system.