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.

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.

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.