Use the reviewed payment display contract
Driver App displays payment-related fields inside order detail and, for limited configurations, a filtered orders summary. These are client projections over returned order data. They are not payment authorization, capture, balance, cash-handling, earnings, payout, refund, settlement, or accounting records.
This contract is source-api-only; no order or financial read, provider call,
cash action, wallet action, payment mutation, or reconciliation is admitted.
Availability
| Display | Current public boundary |
|---|---|
| Payment header | Counts only returned events classified as payment and builds method labels |
| Payments section | Renders every returned event when the event array is nonempty |
| Cash display | Can substitute an order-level cash field and label it as change information |
| Wallet display | Header and event rows use different returned wallet shapes |
| Bill fields | Total, tip, fee, tax, discount, and payment rows remain separate |
| Orders Summary | Optional filtered, loaded-row calculation; not an earnings or payout surface |
| Financial authority | No dedicated Driver earnings/payout route or settlement owner exists in the reviewed UI |
Prerequisites
- Use an authenticated, authorized order read and purpose-minimal financial data.
- Distinguish header projection, event-list projection, bill fields, local orders summary, and authoritative payment/provider records.
- Freeze locale and currency display context when comparing presentation.
- Reject malformed, negative, non-finite, mixed-currency, or unexplained values from operational or financial use.
- Route collection, refund, payout, settlement, and reconciliation to the approved payment/accounting owner, not Driver App display.
Responsibility boundaries
| Owner | Responsibility |
|---|---|
| Order header | Filter payment-classified events and render method labels/change copy |
| Payment event list | Render heterogeneous returned rows and amount presentation |
| Orders Summary | Flatten loaded rows, classify categories, coerce selected fields, and format a local total |
| Order API | Authorize the read and return order/payment relations; not provider settlement authority |
| Payment/wallet/gateway | Own authorization, capture, event semantics, balances, refunds, and settlement |
| Cash-handling owner | Define collection, tender, change, custody, and reconciliation policy |
| Finance/accounting | Own earnings, payouts, taxes, fees, ledger truth, and approved reports |
Inputs and result
Header and event projections
The header filters the returned event array before choosing singular/plural copy and labels. The Payments section renders any nonempty event array without the same filter and reads wallet data from another shape. Counts, labels, and rows can therefore diverge without establishing which projection is financially true.
Cash, wallet, and amount direction
For some cash rows, the UI replaces the event amount with the order-level cash field and displays it positively; other event rows receive a visual minus prefix. These formatting rules do not define amount due, tendered, collected, change owed, debit, credit, refund, wallet balance, or settlement direction.
Orders Summary
The optional summary uses only currently loaded, filtered rows. It flattens recognized groups, classifies a narrow set of delivery outcomes, selects one of two order fields, coerces values, and applies global currency formatting. It does not reconcile payment events, providers, refunds, fees, payroll, cash, or payouts. Loaded versus reported total is pagination context, not finance closure.
Security and privacy
- Do not publish real order, customer, payment, wallet, gateway, currency, amount, token, provider, payout, or account data.
- Do not expose private event schemas, routes, endpoints, identifiers, or provider configuration.
- Treat labels, signs, method counts, formatted amounts, and completed delivery state as untrusted financial presentation.
- Require payment-owner definitions and authoritative receipts before assigning debit/credit, due/paid, refund, balance, payout, or settlement meaning.
- Keep synthetic financial fixtures finite, nonidentifying, zero-egress, and independently reviewed by privacy and finance owners.
Limits and failure states
| State | Required interpretation |
|---|---|
| Missing/empty events | Unknown/not returned; not unpaid or settled |
| Header and rows differ | Different client projections |
| Non-payment row shown | Event list is heterogeneous; not a payment receipt |
| Cash/change text | Returned field presentation, not collection instruction |
| Wallet/gateway label | Method label, not provider authorization or balance |
| Negative-looking row | Visual prefix, not debit/refund direction |
| Completed delivery | Operational category, not payment settlement |
| Summary amount | Local field calculation, not earnings/tip/payout |
| Loaded equals reported total | Pagination state, not reconciled/current finance |
| Malformed/non-finite value | Invalid diagnostic; stop financial interpretation |
Troubleshooting
Header and Payments disagree
They use different filters and wallet shapes. Do not choose one as settlement truth. Escalate the non-sensitive discrepancy to the payment owner.
Cash or Change of appears
Do not calculate collection or change from the display. Follow the operator's approved cash-handling record and policy.
A wallet or gateway row looks successful
The label does not prove authorization, capture, transfer, balance, refund, or settlement. Require an authoritative provider/accounting receipt.
Orders Summary differs from an approved report
Check filters, loaded pages, grouping, classification, field coercion, currency formatting, and realtime changes. Use the approved report as authority; do not adjust orders or payment data from the summary.
Related guides: Understand cash orders and payment events · Review the orders summary · Review order details · Review delivery history · Use the reviewed order state reference contract