How orders, payments, invoices, and tickets fit together
Use this when an order looks paid but not booked, booked but unpaid, missing tickets, waiting for a refund, or blocked from sending a payment link.
KORONA Event keeps operational state and financial state separate. Check both before you resend documents, issue tickets, cancel, refund, or tell a customer the order is complete.
The four state groups
| State group | What it tells you | What it does not prove |
|---|---|---|
| Order state | Whether the order is new, requested, reserved, booked, canceled, or expired. | Whether money has been received or refunded. |
| Payment state | Whether the order still needs a payment, needs a refund, needs both, or is settled. Individual payment attempts can additionally be pending or failed; those belong to the payment transaction, not the order. | Whether tickets were generated or whether the customer can enter. |
| Invoice state | Whether an invoice exists, needs payment, is paid, requires a refund, or is refunded. | Whether the booking should remain active operationally. |
| Ticket state | Whether tickets or vouchers exist and can be used for entry or redemption. | Whether the invoice is correct or the payment provider has settled the money. |
Order states
Order states
Order state describes the operational progress of an order; read payment and invoice state separately.
| Option | What it does | When to use it | Watch out for |
|---|---|---|---|
| New | Marks an order that is still open or has not progressed to a customer-facing result. | Use it while an order is being created or reviewed before request, reservation, or booking. | Check before sending payment links or documents. |
| Requested | Records a customer request that is waiting for review or a later staff action. | Use it when the booking must not be confirmed automatically. | Do not treat it as a final booking. |
| Reserved | Holds capacity until a reservation deadline or another action progresses the order. | Use it for temporary holds and pay-later workflows. | The reservation can expire and release capacity. |
| Expired | Marks a request or reservation that passed its allowed deadline without progressing. | Use it to identify orders that no longer hold their previous place in the workflow. | Check whether the customer completed a replacement order later. |
| Booked | Confirms the order operationally. | Use it when the selected offers are accepted as a booking. | Booked does not prove that payment or ticket generation completed. |
| Canceled | Ends the operational order and prevents it from being treated as active. | Use it after an approved cancellation workflow. | Payment, refund, invoice, capacity, and customer communication may still need separate action. |
Order payment states
Order payment states
Order payment state summarizes whether money is still due, settled, or requires refund work.
| Option | What it does | When to use it | Watch out for |
|---|---|---|---|
| Open payment | Shows that the order still has an amount that needs to be paid. | Use it to find orders that need payment follow-up or an available payment action. | Check invoice state and open items before sending a payment link. |
| Needs refund | Shows that money should be returned or refund follow-up is still required. | Use it to route the order into the team’s refund process. | It does not prove that the customer has received the money. |
| Action needed | Shows that the order contains both an amount to collect and an amount to refund. | Use it to identify mixed financial corrections that need deliberate review. | Review invoice details instead of assuming the two amounts cancel each other out. |
| Settled | Shows that the order has no remaining payment or refund difference at order level. | Use it as the order-level financial completion signal. | Still check individual invoices and provider settlement when finance detail matters. |
Invoice payment states
Invoice payment states
Invoice payment state describes what payment or refund work remains for one invoice.
| Option | What it does | When to use it | Watch out for |
|---|---|---|---|
| Requires payment | Shows that the invoice still needs payment. | Use it when collecting an open invoice through an available payment action. | A payment link exists only when the invoice and provider support it. |
| Requires refund | Shows that the invoice needs a refund or refund follow-up. | Use it to identify invoices that must enter the refund process. | The provider transaction can still be pending or require manual handling. |
| Refunded | Marks the invoice as refunded. | Use it after the approved refund workflow records completion. | Confirm provider and customer receipt when investigating a disputed refund. |
| Paid | Records payment for the invoice. | Use it when the invoice amount has been paid or deliberately marked paid. | Paid does not prove that the order is booked or tickets were generated. |
Ticket states
Ticket states
Ticket state describes whether a ticket is ready, usable, consumed, restricted, or no longer valid.
| Option | What it does | When to use it | Watch out for |
|---|---|---|---|
| Pending | Shows that ticket activation or final state is not complete yet. | Use it while waiting for ticket generation or synchronization to finish. | Do not promise entry until the ticket becomes active or its source confirms validity. |
| Active | Shows that the ticket is currently valid for its configured entitlement. | Use it as the normal ready-for-entry state. | Date, time, entitlement, and duplicate-scan rules can still affect admission. |
| Used | Shows that the ticket’s usable entitlement has already been consumed. | Use it to investigate a repeat or duplicate entry attempt. | Check scan history before overriding an admission decision. |
| Expired | Shows that the ticket is outside its valid period. | Use it when the configured validity has ended. | Confirm the selected event or admission date before rejecting the customer. |
| Locked | Prevents the ticket from being used while a restriction is active. | Use it when an operational or external-system rule deliberately blocks entry. | Review the lock reason and owning system before changing it. |
| Cancelled | Shows that the ticket was canceled and is no longer valid for entry. | Use it after the related order item or ticket has been canceled. | Check whether a replacement ticket was issued. |
| Unknown | Shows that KORONA Event cannot determine a reliable ticket state. | Use it as a signal to inspect ticket source, synchronization, and scan history. | Do not infer validity without checking the source system. |
How to read a common order
- Start with the order state on the order overview.
- Check whether the order has Open items.
- Open Documents when financial state matters.
- Check whether payment actions such as Initiate payment, Copy payment link, or Send payment link email are available.
- Open Attendees or the document downloads when entry, tickets, vouchers, or personalization matter.
- Open History when you need to see how the order reached its current state.
State combinations that need care
| What you see | What it usually means | Safe next check |
|---|---|---|
| Booked order with unpaid invoice | The booking may exist, but payment follow-up is still needed. | Check Open items, invoice state, and available payment-link actions. |
| Paid invoice with missing tickets | Financial state looks complete, but document or ticket generation may not be complete. | Check Attendees, ticket downloads, products, and order History before resending email. |
| Reserved order with a deadline | Capacity is held only until the reservation or unpaid-order deadline. | Check the deadline before promising the customer that places are still held. |
| Canceled order with a payment | The operational order ended, but a refund or accounting correction may still be required. | Check invoice state, refund indicators, and finance process before editing services. |
| Failed payment with a created order | The customer may have started checkout without completing payment. | Check whether the order is still payable, expired, auto-canceled, or replaced by another order. |
| Refund required | A refund or refund follow-up is expected, but the customer may not have received money back yet. | Check invoice state, payment provider state, and your team's refund responsibilities. |
What customers see while paying online
Pending and failed payment pages show Order reference below the payment guidance. Customers can quote it when contacting the merchant so the order can be found. The reference is not proof of payment. Customers waiting for payment confirmation should keep the payment page open and let it update before paying again or placing another order. A longer wait alone does not mean that payment failed.
If payment was not completed, Try payment again returns the customer to the payment options for the same order. An incomplete card verification may instead return directly to the card form. The available action depends on the payment provider's confirmed result and whether the order can still be paid. If the order can no longer be paid, the page explains why and offers Return to shop.
For Google Pay selected during the regular Lynck checkout, an incomplete card verification may return the customer to the Google Pay button for the same order. The customer selects the button and authorizes payment again. Follow any new bank verification prompt. If the shop offers other methods, select Choose another payment method to pay for the same order another way. The shop checks the previous payment before showing the options. If it is still waiting for confirmation, keep the payment page open and wait for the status to update.
For Google Pay Express started from the cart, Try payment again may appear after an incomplete bank verification. Select it to return to the payment options for the same order. Choose Google Pay and approve the payment again, then complete any bank verification prompt. If the shop is still waiting for confirmation, wait for the payment status to update before trying another payment.
For payment methods that confirm later, a pending result can be expected. Do not advise a customer to create another order or manually record a payment just because confirmation is delayed.
Rules of thumb
- Do not treat Booked as proof of payment.
- Do not treat Paid as proof that tickets were generated.
- Do not resend an email until you confirm the order has the expected documents.
- Do not create a manual payment link when the payment link action is unavailable.
- Do not edit paid services or quantities until you understand the refund and invoice result.