Transaction API

Optional, but strongly recommended. One endpoint that returns closed payment transactions. This is what produces the turnover reports the partner sees in the Cheers CMS.

Required Data

Only two fields are mandatory.

Data	Required	Notes
Transaction identifier	Yes	Deduplication key. A given identifier is stored exactly once, ever.
Creation timestamp	Yes	ISO-8601 with a time zone offset, e.g. 2026-07-28T14:32:05+02:00. Cheers derives the start of the next fetch from it.
Everything else	No	Stored raw, exactly as sent, and shown to the partner in the CMS.

Everything Else Is Free-Form

The body of a transaction is freely extensible: whatever your POS sends is preserved. You do not need to fit a Cheers schema, and adding fields later breaks nothing.

That said, partners consistently ask for the following, so include what your POS can produce:

• Line items -- product identifier, quantity, unit price, discount
• Payment parts -- payment method and amount per part
• Total amount
• Service charge
• Tip
• Discount
• Currency
• Void / cancellation timestamp

Use the same product identifiers

Line-item product identifiers should be the same values returned by the Product API. That is what makes per-product turnover reporting possible.

Example

[
  {
    "id": "TRX-2026-0001",
    "createdAt": "2026-07-28T14:32:05+02:00",
    "total": 4270,
    "currency": "HUF",
    "items": [
      { "productId": "SKU-1042", "quantity": 2, "unitPrice": 1890, "discount": 0 },
      { "productId": "MOD-01", "quantity": 1, "unitPrice": 150, "discount": 0 }
    ],
    "payments": [
      { "method": "CARD", "amount": 4000 },
      { "method": "CASH", "amount": 270 }
    ],
    "serviceCharge": 340,
    "tip": 0
  }
]

The same response shape rules as the Product API apply: plain array or wrapped object, any field names, GET or POST, optional pagination.

Time Filtering

A start-time parameter (e.g. createdAtFrom) is strongly recommended. Cheers sends the timestamp of the most recently stored transaction so that only new ones have to be transferred.

• The filter may be inclusive (>=). The repeated boundary transaction is filtered out on our side by its identifier.
• Without a time filter, Cheers requests the entire set on every run. That is acceptable at low volume and unworkable at high volume.

Deduplication and Immutability

• Deduplication is by identifier. An identifier already stored is skipped.
• Stored transactions are never updated. Cheers does not re-read or refresh a transaction it has already saved.
• Consequently, a later modification only reaches Cheers if it arrives as a new transaction with a new identifier -- a void, for example, must be a separate record rather than an edit of the original.

Creation timestamps must increase monotonically in insertion order

The next fetch starts from the newest timestamp already stored. If a transaction is inserted later but carries an earlier creation timestamp -- a backdated record, a delayed upload from an offline terminal, a batch replay -- it falls behind the watermark and is never fetched.

If your POS can produce backdated records, either give them a creation timestamp at insertion time, or expose an additional filter based on insertion order rather than business time.