Settlement Attribution

Fiest reports two related fields on sold orders:

• paymentMethod describes how the order was settled.
• orderOrigin describes how the order entered Fiest.

Keep these fields separate in your integration. A marketplace name in paymentMethod does not prove that the order came from that marketplace's API.

Manual and integration-origin orders

When restaurant staff record a Wolt settlement manually, Fiest reports:

{
  "paymentMethod": "wolt",
  "orderOrigin": {
    "kind": "manual",
    "provider": null
  }
}

A future order ingested from a reviewed Wolt integration remains distinguishable:

{
  "paymentMethod": "wolt",
  "orderOrigin": {
    "kind": "integration",
    "provider": "wolt"
  }
}

The same separation applies to supported marketplace settlement methods such as Wolt Catering, ResQ, and Uber Eats. Fiest never exposes the private payment metadata used to resolve these public values.

Accounting summaries

The accounting summary groups amounts by the effective settlement method. Manually recorded marketplace settlements therefore appear under their marketplace key instead of the generic manual bucket. Refunds, VAT, and net sales remain reconciled within that method.

These accounting method totals are raw and do not apply Dashboard payment corrections. For a correction-aware bookkeeping import, also read the payment report for the identical business period and follow the bookkeeping checks. A correction reallocates existing sales between methods; it does not change the order origin.

Use find orders when you also need the public orderOrigin distinction for individual sold orders. Payment-method filters match the effective method, so payment_method=wolt includes Wolt-settled orders regardless of whether the origin was manual or integration-based.

Provider payment references

With approved fiest.restaurant.read and fiest.orders.read scopes, call find orders, then pass the returned opaque orderId unchanged to get order details. The shared Services capability returns retained payment-provider references alongside the sold-order details. Partner API and MCP reads use the same evidence; no additional payment scope is required.

Keep provider and each identifier type separate. Never substitute a checkout or session ID for a missing transaction ID. The provider name is a bounded string; future reviewed providers can use the same response shape. The current adapter returns only Viva, SumUp, and Stripe evidence.

An entry can refer to a child receipt from a completed tab or split payment. Retain the entry's receiptHash rather than assuming every reference uses the parent order's receipt. Failed or pending tracking attempts are excluded; previously paid or refunded split legs can retain their original payment reference. References contain no card details or provider credentials.

Handle availability explicitly:

• An absent field remains valid for an older compatible response.
• paymentReferences: null means the reviewed payment-reference read is unavailable. Keep the other order details usable.
• payments: [] means no matching retained references were found. It does not prove that no payment occurred.
• truncated: true means the bounded collection is incomplete. At most 50 references are returned; do not treat it as a complete reconciliation.
• Missing historical identifiers, amounts, currencies, or timestamps remain null. Do not infer an identifier from an order ID or receipt hash.

recordedAmountMinor is a stored amount in minor units, not an independently verified capture or settlement amount. These references are not a complete tender, refund-event, fee, or payout ledger. Do not sum them as recognized sales or invent refund links. Continue using the accounting summary and payment report for bookkeeping totals and correction evidence.

Supported manual settlement keys

The currently recognized manual settlement keys are:

• wolt
• wolt_catering
• resq
• mobile_pay
• uber_eats
• invoice
• manual_card_reader

An unclassified manual settlement remains manual. Unknown or unsupported values fail closed to the documented fallback instead of exposing raw metadata.