Mobile Payments & Transactions

Review live payment history, open invoice balances, failed payments, refunds, financing records, and disputes safely from mobile.

IntermediateownermanagerUpdated 2026-08-05

Mobile Payments & Transactions

Owners and managers with View Billing permission can open More > Payments & Transactions in the native app. Every screen reads the currently selected organization's production payment ledger; the app does not substitute sample customers or transactions when a period is empty or unavailable.

The Finance section also includes Payment Collection. That row routes into the same live Payments & Transactions workspace so the collection entry point is always reachable without creating a second ledger or an editable-looking placeholder. Recording money still happens through an eligible invoice collection flow and retains the permissions described below.

Available Views

  • Transactions shows payments, refunds, failed entries, and voided entries

across the last 30 days, quarter, year, or all time.

  • Partial & Split Payment and Create Credit Memo show real open invoice

balances that are eligible for those workflows.

  • Refund or Void shows successful transactions with refundable value left.
  • Failed Payment Recovery shows failed ledger entries that need follow-up.
  • Financing Application shows only financing activity already recorded in

the payment ledger.

  • Payment Disputes shows only transactions carrying real provider dispute

metadata.

Production-Safety Limits

These seven workspace screens are read-only in this release. Refund, void, split-payment, credit-memo, retry, financing, and dispute buttons are not shown unless a production-safe provider operation is available. In particular, no financing provider or automated Stripe dispute feed is connected yet, so empty states say that directly instead of simulating an application or dispute.

Recording a manual mobile payment still requires Manage Billing plus view permission for the linked lead, estimate, job, or invoice. Existing collection flows keep their normal confirmation and payment-setting rules.

Collecting or Requesting an Estimate Payment

Open an estimate and use Payments & deposits:

  • Request opens the same Review & Send screen used for estimates. Review

or edit the email and SMS before sending. The secure link opens the customer's estimate portal directly to Payments, where card and ACH entry stay embedded on the portal page.

  • Add lets staff choose a deposit or other payment amount. Choosing

Card immediately offers Tap to Pay or Enter card details. Entered-card collection opens Stripe's secure PaymentSheet inside the app. Tap to Pay opens Stripe Terminal on a compatible, NFC-enabled device.

  • Check and Other record a payment already received. Other expands to

the payment types configured for the current workspace.

Tap to Pay requires a live connection, Stripe configuration, a complete company address, and a supported device. For live payments, Android Developer Options, USB debugging, and wireless debugging must be off. Stripe test-mode workspaces automatically use a simulated reader so test cards do not require a production contactless transaction. Card details never pass through CleanEstimate Pro's own form fields; Stripe's native payment UI collects them.

After Stripe confirms the payment, the app refreshes the estimate balance from the production payment ledger. If that refresh is delayed, the app says the payment was received and tells staff not to charge the card again; pull to refresh after a moment to retrieve the updated balance.

Collecting an Invoice

The invoice collector keeps Card, ACH, Check, and Other in the compact standard row. Opening Other reveals Cash and the alternate methods enabled for the workspace, such as Zelle, financing, bank transfer, Venmo, Cash App, or PayPal. Selecting Check opens the check and office-reference fields. The customer still receives exactly three configured tip choices plus 0 Tip.

Before a payment is posted, the collector shows a final confirmation with the amount, method, and tip so the person holding the phone can catch a selection mistake without writing a payment to the ledger.

The collector preserves cents from entry through confirmation and the success receipt. For example, a payment entered as $0.01 remains $0.01 after it is recorded instead of being rounded to $0. This applies to partial payments as well as a final balance payment.

Card collection uses Stripe hosted checkout in the device browser; it is not native Tap to Pay. Returning to Clean Estimate does not mark the invoice paid by itself. The app shows a browser-return screen where staff can refresh the server-backed invoice status or treat checkout as unfinished and choose a different method. Payment is complete only after Stripe reports it and the invoice ledger reflects the result.

The customer portal reuses an existing open Stripe checkout instead of creating multiple payable links for repeated taps. It first verifies that the hosted amount still matches the current invoice; a stale session is expired before one generation-safe replacement is created. Discounted or otherwise reconciled invoices fall back to one exact-total checkout row when their older service breakdown no longer adds up to the payable total. An expired or asynchronously failed attempt can be replaced safely, while a completed paid session cannot be reopened. Every collection path also rejects a positive payment when the invoice has no remaining balance, including card, keyed-card, and manual payment entry.

The collector's back button always returns to the invoice. This works when the collector was opened from invoice detail and when a list action opened it directly. Header icon buttons keep a native Android hit target so tapping the visible arrow works even when the icon itself is under the finger. Invoice and payment headers also stay below the Android status bar and camera cutout.

Invoice list filters use delivery and balance truth instead of trusting an imported status label alone. Unsent means the unpaid, non-void invoice has no send timestamp. Overdue means the invoice was sent, its due date has passed, and a positive balance remains. An unsent draft is never added to the overdue total solely because it has an old due date. The app sends its device-local date with the filter request so the Overdue tab and each row change day together at local midnight. A zero-total unpaid draft remains sendable and is not labeled paid merely because its balance is zero.

The compact invoice ledger also supports amount-due sorting and keeps the customer, service type, complete service address, linked job, sent date, due date, balance, and status-specific activity visible in each slim row. Invoice detail keeps the same customer/service context above Sent, Due, Status or Overdue, and Viewed metadata, with Send/Resend, Preview, Call, Download, reminder, and payment collection actions shown only when their real data and permissions allow them. Invoice details starts collapsed while Line items starts expanded, including an explicit empty state when no items are recorded. Secondary record links stay inside collapsed More actions so the billable work remains visible without being pushed below duplicate action rows.

Was this article helpful?

Still need help? Contact support