Interpret order payment information
Business App can show payment-related information returned with an order. Use these fields to identify what the order view displays, then use your approved payment or accounting record for financial decisions. The app does not provide a native control here to collect, charge, capture, refund, settle, or reconcile a payment.
Before you start
- Sign in to the intended project and business scope, then open the intended order from Orders.
- Match the order number and business before reading payment information.
- Refresh and reopen the order when its amounts or status may have changed.
- Treat customer, order, wallet, gateway, and amount information as private operational data.
States and fields
| Visible term or state | Safe interpretation | Availability or gate | Operator action |
|---|---|---|---|
| Payment method | The singular heading can show one derived payment label. It uses the order-level payment method only when the returned payment-event array is empty or missing. | Zero or one returned event is classified as a payment. | Record the visible label without treating it as proof of payment. |
| Payment methods | The header found more than one returned event classified as a payment. | More than one returned event uses the header's payment classification. | Treat the labels as display information, not a reconciled timeline. |
| Blank value under Payment method | A nonempty event array contained no rows classified as payments, so the derived header list is blank and the order-level fallback is not used. | The returned array is nonempty, but its payment-classified count is zero. | Do not guess the method; use the approved payment record. |
| Cash | A returned method is labeled as cash. | The returned order or event uses the cash gateway label. | Follow the business's approved cash-handling process outside this article. |
| Change of amount | The order's returned cash field is formatted as change information. | A cash payment event exists and the returned cash value is greater than zero. | Do not calculate cash due, cash received, or change owed from this label alone. |
| Cash or credit-points wallet label | A returned wallet type maps to a wallet display label. | The event includes a recognized wallet relationship. | Do not infer a wallet balance, transfer, or settlement. |
| Payments | The order view lists returned payment-event rows and their formatted amounts. | The returned payment-event array is nonempty. | Read each row as a display projection; do not sum or net rows as an accounting result. |
| Subtotal, discounts, taxes, fees, delivery fee, driver tip, and Total | The order bill presents applicable pricing fields separately. | The visible total is nonzero, and each optional field meets its own data and configuration conditions. | Compare the displayed bill with the approved order or accounting record when accuracy matters. |
| Select Paymethod | The order search can narrow results by one returned payment-method option. | The payment-method list loads and the Business App search modal is available. | Apply the filter, then verify each matching order; filter membership is not payment status. |
How the displays can differ
The header and Payments section are different projections of the returned order data. The header counts only events classified as payments. When the event array is empty or missing, it falls back to the order-level payment method. When the array is nonempty but contains no classified payment rows, the singular heading remains and its derived value can be blank; it does not use that fallback. The Payments section appears for any nonempty event array and can render rows that the header did not count.
For some cash rows, the displayed amount comes from the order's cash field. For other rows, the app adds a minus sign to the returned event amount. These formatting branches do not establish amount due, tendered, collected, credited, debited, refunded, or settled.
Keep these values separate:
- The order-level payment method.
- Header payment-method labels.
- The cash or Change of field.
- Individual Payments event amounts.
- Wallet and gateway labels.
- The order Subtotal, optional bill rows, and Total.
Variations and limits
- A missing field can mean that data was not returned, the order does not use that branch, the signed-in scope cannot read the order, or the current app and service behavior differs. It does not prove unpaid, paid, refunded, or settled.
- Singular and plural method labels depend on classified events, while the Payments section depends on a nonempty event array. Their counts can differ.
- An empty or missing event array and a nonempty array with zero classified payment rows are different states. Only the empty or missing array uses the order-level header fallback.
- Payment-method filters narrow order reads by method identifier. They do not filter by authorization, capture, refund, settlement, processor result, or timing.
- Order totals can remain from an earlier read when a realtime update changes another part of the local order. Refresh before an amount-dependent decision.
- This reference interprets visible source-defined fields only. It does not guarantee deployed availability, provider behavior, settlement state, or processing time.
Troubleshooting
| What you observe | Interpretation | Next action |
|---|---|---|
| The order remains loading or shows Network Error | The scoped order read did not complete successfully. | Return to Orders, restore connectivity, refresh, and reopen the order. Ask the project administrator to verify business scope if it persists. |
| A payment method or amount is missing | The corresponding relationship or conditional field may be absent, unavailable to the current scope, or not returned. | Do not guess. Verify the intended order and use the approved payment record. |
| The header and Payments disagree, or the header value is blank | They use different event filters and wallet fields. A nonempty array with zero classified payment rows does not use the order-level header fallback. | Do not guess the method. Record the non-sensitive discrepancy and ask the payment owner to reconcile it. |
| Change of appears for cash | The app formatted the returned cash field with that label. | Do not derive cash to collect or change to return; follow the approved cash-handling record. |
| A row is blank, unfamiliar, or has a minus sign | The event did not map cleanly to a known label, or the UI applied its amount-formatting branch. | Do not assign debit, credit, refund, or settlement meaning. Escalate to the payment owner. |
| Filtered results look incomplete | The option list, current filters, pagination, or order reads may be incomplete. | Clear or reapply Select Paymethod, refresh, and verify the intended order individually. |
| Status changed but totals look unchanged | A realtime update may not have replaced the earlier total fields. | Refresh the queue and reopen the order before using the amounts. |
Related articles
:::note Visual status authorized synthetic capture program with accepted exact asset allowlist and independent visual QA :::