Purpose: Document the people, systems, data, controls and exceptions in a real merchant workflow.
Written and reviewed by Raied Muheisen · Last reviewed June 21, 2026
Trigger
A deposit, progress payment or final invoice becomes due.
Actors
- Customer
- Office or field staff
- Project/invoice owner
- Bookkeeper
- Payment provider
Normal workflow
- Business issues an approved estimate, contract or invoice.
- Customer receives an approved payment method.
- Payment is accepted in person, by link or through an approved remote tool.
- Transaction is matched to customer, project and invoice.
- Receipt or acknowledgment is sent.
- Accounting status and remaining balance update.
- Refund or dispute follows documented authorization records.
- Settlement is reconciled.
Exceptions
- Partial payment
- Changed scope
- Duplicate payment
- Keyed or remote payment dispute
- Failed link
- Refund after project change
- Payment not matched to invoice
Required data
- Customer and project
- Invoice and balance
- Authorization evidence
- Payment channel
- Tender and transaction ID
- Refund/dispute record
- Deposit reference
Controls and ownership
- No card data in notes or messages
- Approved payment links and tools
- Invoice matching
- High-ticket authorization record
- Settlement reconciliation
Acceptance tests
- ☐ Deposit and final payment
- ☐ Partial payment
- ☐ Failed payment
- ☐ Refund
- ☐ Invoice-to-deposit reconciliation
