Setting prices, recomputing fees, establishing discrepancies

A dealer prices with a markup on purchase cost and finds at year end that one product group earned nothing. The reason lies in the channel fees nobody ever recomputed. The markup was right — it was simply calculated on the wrong basis.

The five branches answer four different questions about the same selling account. They do not depend on each other, and you do not need all of them — but setting prices without recomputing fees means calculating on a basis you do not know.

What this case requires

• A net target you want to reach. With targetNet the pricing policy works backwards; according to the contract a fixed markup guarantees no target amount.
• Willingness to read fee lines. A statement nobody checks is an invoice you simply pay.
• Two checkpoints for the reconciliation. Source and target each need a state; sourceCheckpoint and targetCheckpoint are required fields of the reconciliation.
• A recipient for events if you do not want to poll. A subscription without a reachable recipient delivers nothing.

The sequence

The table names the responsible call per stage and what exists afterwards. The reasoning for why a stage cannot be skipped follows below it.

Why each stage is needed

1. Create the pricing policy. POST /commerce/v1/pricing-policies knows, besides a fixed markup, also targetNet: you name the net that should remain and the policy works backwards — with channel fees, service fees and discounts, depending on what you include. That is the difference between revenue and earnings.
2. Check the fee statement. GET /commerce/v1/fee-statements returns basis, feeBasisPoints and feeAmount per line, plus for corrections the reference to the adjusted line. A fee can thus be recomputed instead of believed.
3. Run the reconciliation. POST /commerce/v1/reconciliations compares sourceCheckpoint with targetCheckpoint and returns counts, integrity with checksums for source and target, and discrepancies with severity. The decisive figure is criticalRemaining, the number of critical discrepancies remaining; the reconciliation is not yet activated in the contract.
4. Subscribe to events. POST /commerce/v1/webhook-subscriptions sets up a signed delivery. Polling on a timer instead creates load and still notices a gap only late.
5. Re-read the stream. GET /commerce/v1/events returns events with streamId and sequence. Retrieval uses stable cursor pagination (cursor, limit).

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: preisregel-netto-2026-09' \
  -d '{"strategy":"target_net","scope":{"catalogItemIds":["<catalogItemId>"]},"targetNet":{"target":{"amountMinor":4500,"currency":"EUR"},"calculationBasis":"item_price","includeChannelFees":true,"includeServiceFees":true,"includeDiscounts":false},"revision":"<revision>"}' \
  'https://commerce-preview.invalid/commerce/v1/pricing-policies'

What you end up with

In the end you can recompute every fee line, have offer prices derived with targetNet from a target amount and the fees included, and read from criticalRemaining after a reconciliation how many critical discrepancies between source and target remain. The contract contains no purchase costs; you determine your margin with your own figures.

Where to find this in the documentation

The binding field lists, error codes and sample responses live in this surface’s OpenAPI contract at docs.tapinomahub.com (tapinoma-commerce). All use cases arranged by surface and role: overview of the use cases.