Describe what is actually being sold.
Separate custom development, support, subscription access, automated digital service, content, and pass-through costs. Identify the seller, customer type, contracting entity, acceptance event, and which adviser confirms the treatment.
Do not collapse every currency into one label.
CZK may be the audience-facing reference while contract currency, provider charge, settlement, refund, and accounting currency differ. Agree on rounding, exchange-rate ownership, timestamps, and what appears in receipts and invoices.
Verify the client’s real provider accounts.
Eligibility can depend on entity, bank, country, service, card, identity checks, and provider policy. Use client-owned accounts approved for the transaction. Never design around assumed access or ask a microsite visitor for payment.
Model pending, failed, duplicated, refunded, and disputed.
Use idempotent operations where appropriate, preserve provider identifiers, show honest user messages, and decide who can retry or override. A webhook and a browser return should not independently create the same order.
Define the source of truth.
Connect payment events to the order, invoice, customer record, refund, and accounting handoff. Exceptions need an owner and a queue. Reports should distinguish customer-facing status from provider and settlement status.
VAT and invoicing are approval inputs, not code guesses.
Customer status, place of supply, service classification, VAT registration, invoice requirements, and evidence can change the design. The Czech Financial Administration is an official starting point, but the client or its qualified tax adviser must decide what applies to the actual transaction.