One sale can produce an order, several payment attempts, an invoice and a later settlement record. They describe related parts of the transaction, but they answer different questions.
Treating them as interchangeable makes exceptions harder to investigate. A clearer workflow gives each record a purpose and connects them through references your team can follow.
Give each record a clear job
The order describes the commercial request and what the business needs to fulfill. A payment attempt records an interaction with a payment provider. The invoice records the commercial billing document. Settlement evidence helps explain what the provider transferred and how that relates to transactions and adjustments.
The precise lifecycle depends on your provider, business model and applicable requirements. The operating principle is to preserve the distinctions. A payment confirmation alone does not explain fulfillment, document correction or the amount ultimately received in a bank account.
Agree which system is the source for each fact. This helps a support or finance colleague investigate without treating every difference as a new sale or a failed payment.
Walk through an exception
Consider a hypothetical order where the customer retries after a slow response. Your team now sees two attempts. Before collecting again, it needs to determine the outcome of each attempt using the provider's evidence.
If the order is later partially refunded, the team needs the original payment reference, the refund outcome and the remaining commercial balance. It may also need a related document correction, according to the applicable process. Rewriting the original record without preserving the relationship would make the story harder to reconstruct.
Create an exception queue with an owner, a reason and a next action. “Needs attention” is too broad if one case is waiting for provider confirmation and another is waiting for a customer's decision.
Define what orchestration owns
Payment orchestration coordinates payment workflows and provider connections. The merchant, payment provider and bank still have their own roles. Confirm those responsibilities in the actual commercial and technical arrangement.
When comparing options, ask how an attempt is identified, how delayed provider responses are handled and how an operator investigates an uncertain result. Confirm supported providers individually. Avoid assuming that a common interface creates identical behavior across every provider.
Ignite Commerce is Ignite's payment orchestration product. It is a technology layer, not a payment service provider or bank. A useful conversation begins with your provider relationships and the exceptions your team needs to resolve.
Prepare invoice data before adding complexity
Identify who owns customer details, item descriptions, commercial amounts and the references between documents. Review how corrections are requested and approved. Test whether a finance colleague can explain a sample transaction from its records without relying on private messages.
For e-invoicing, start by identifying the jurisdictions and transaction types involved, then confirm current requirements with the relevant authority and a qualified adviser. This article describes operational preparation; it is not a jurisdiction-specific compliance checklist or a compliance assurance.
Give the implementation team a clearly scoped requirement set. “Support e-invoicing” is less useful than a defined document flow, ownership model and acceptance process. Ignite Commerce and Ignite Commerce are the relevant Ignite products to discuss in that context.
Review the whole chain
Choose a normal sale, a retry, a refund and a corrected document. Walk each through with operations and finance. Record which evidence confirms completion and who investigates when it is absent.
This produces a practical evaluation brief: records, relationships, exceptions and responsibilities. It also gives your team a shared vocabulary for discussing a financial workflow without reducing it to a single “paid” label.