Orders, payments, and fulfillment

Read the records separately

Open Admin → Orders and select an order. Review its customer, items, totals, payment attempts, invoices, credit notes, and refunds. The detail screen loads these related records; it is the starting point for investigating a customer's report.

Core order status is pending, paid, or cancelled. Payment status has additional states, including failed, expired, refunded, and partially refunded. A payment attempt represents an interaction with a provider, not a separate order. Do not interpret an old failed attempt as proof that a later attempt did not succeed.

References: order detail, OrderStatus, and PaymentStatus.

Confirm payment before fulfilling

A customer's return from hosted checkout is not by itself proof of payment. Check the Agovena payment record and provider confirmation. If the provider reports payment but Agovena remains pending, investigate webhook delivery and background processing before asking the customer to pay again.

A paid order is not necessarily a shipped parcel, delivered code, downloaded file, or active server. Fulfillment is supplied by the relevant modules, which can add sections to the order detail. Review their state and any failed jobs independently. Never use an invented global shipped or fulfilled order status to represent module work.

For a delivery complaint, gather the order number, payment reference, purchased capability, and the most recent successful fulfillment step. Compare them with the customer account and provider. Avoid exposing keys, downloaded goods, or provider tokens in support messages.

Record a manual payment only when money is confirmed

The order screen can expose Record payment when the payment is pending and your account has payments.record. Supply a meaningful external reference, confirm the action, and complete recent-password confirmation when requested.

This records an offline or otherwise confirmed payment. It does not charge a card or check a bank account for you. Verify amount, currency, beneficiary, and order identity before using it. Do not use manual payment to hide a failing gateway: marking an order paid can trigger downstream delivery.

After recording, reopen the order and verify payment, invoice, and fulfillment state. Keep the bank/provider evidence in your authorized business records, not in a public issue.

Cancel unpaid orders carefully

The unpaid cancellation action is available only when the order qualifies and you have the required order-cancellation or invoice-void permission. It requires confirmation and recent-password verification. A paid order cannot be treated as an unpaid cancellation; use the applicable refund and credit-note workflow instead.

Store settings include an unpaid-order cancellation threshold. Its default is zero; review the setting's help and business policy before enabling automatic cancellation. The scheduler evaluates stale unpaid orders hourly, so cron must run.

Before cancelling an apparently unpaid order, check for a delayed provider confirmation. Reconcile any late payment rather than silently keeping both a cancelled order and unaccounted money.

Keep invoices and refunds consistent

The detail screen supports linking and unlinking eligible invoices with invoice-management permission. Availability is constrained by order/payment state and the related invoice's status and financial records. Do not change database links directly to evade a disabled action.

A credit note documents a financial correction; a provider refund moves money through the provider. Verify both relevant records and the remote result. Refund support differs across extensions. Paddle supports full and partial adjustments; Tebex remains full-refund only in the current first-release capability surface. Review payment setup and limits.

At the end of each operating day, review pending payments, cancelled orders with late confirmations, failed delivery jobs, and refund discrepancies. Escalate with sanitized references and the affected release, not raw customer data. Use troubleshooting for operational checks.