> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/integration/web-plugins/woocommerce/order-lifecycle-and-operations.md). # Order lifecycle & Operations How the SEB E-commerce Payment Gateway plugin for WooCommerce handles orders, order statuses, and day-to-day operations ## How order statuses change Two things update an order after your customer pays: the customer returning to your store (immediate), and a server-to-server **callback notification** from SEB E-commerce Payment Gateway (authoritative). Neither path trusts the message it receives — both re-check the real payment status with the gateway before touching the order ([how this is verified](/integration/web-plugins/woocommerce/configuration.md#how-callback-notifications-are-verified)). | Payment status at the gateway | WooCommerce order status | What it means / what happens | | --------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- | | Payment page opened, not finished | *Pending payment* | No action needed yet | | Sent for processing / Authorized | **On hold** (note added) | Money reserved, not yet captured. Capture in the Merchant Portal; the order then moves on automatically | | Captured / Settled | **Processing** | Paid. Standard WooCommerce behavior follows: stock reduced, "order confirmed" email sent | | Cancelled / Abandoned / Failed | **Cancelled** | Customer cancelled, dropped out, or payment failed; the customer is returned to checkout to retry | Notes for merchants: * **A paid order lands in *****On hold***** if your shop authorizes first.** The money is reserved, not captured, and the order is waiting on you: capture it in the Merchant Portal () and the order moves to *Processing* on its own. * **Once a payment is captured or settled, the order shows *****Processing***, exactly like any other WooCommerce payment method — stock reduced, confirmation email sent. Fulfil it as usual and mark *Completed* yourself. * **If an order sits in *****Pending payment*** longer than a few minutes after the customer says they paid: check the payment in the Merchant Portal first (see Edge cases below). ![A paid SEB E-commerce Payment Gateway order in WooCommerce → Orders → order view, showing status On hold (this shop authorizes first), the transaction/payment ID next to the payment method, and the order notes recording the payment progression.](https://1157570179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBDtfypkI85zidcVwaDj%2Fuploads%2F9W3DmFu1VNy1M2cFurW0%2Fwc-order-detail-on-hold.png?alt=media) ## What you do where | Task | Where | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | See payment status per order | WooCommerce order view (status + order notes; the transaction ID on the order is the gateway's payment ID) | | Capture a pre-authorized payment | Merchant Portal | | Cancel an unpaid payment | Merchant Portal (order is cancelled automatically) | | Issue a refund | Merchant Portal — WooCommerce has no Refund button for this payment method; the order moves to *Refunded* automatically once the gateway confirms it | | Reconciliation / settlement reports | Merchant Portal — orders link to payments via the transaction ID | ## Edge cases * **Callback never arrives** (misregistered URL, firewall): orders stay *Pending*/*On hold* even though the payment progressed. Fix the callback registration ([Configuration](/integration/web-plugins/woocommerce/configuration.md)), then trigger a fresh notification from the portal or contact SEB support. The plugin has no scheduled re-check. * **Duplicate notifications** are recognized and ignored safely. * **Customer pays but closes the browser before returning:** the callback still completes the order. * **Currency/amount mismatches** are prevented at initiation — the exact order total and currency are sent to the gateway. * **A saved card is no longer accepted** by the gateway: the customer sees *This saved card can't be used. Please pay with a new card.*, the order is cancelled like any failed payment, and the card is removed from their saved cards. See [Saved cards](/integration/web-plugins/woocommerce/configuration.md#saved-cards). ## For developers Callback endpoint: `POST https://your-store.example/?wc-api=egw_checkout_callback` with JSON `{type, paymentId, merchantReference, paymentStatus}`; `merchantReference` is the WooCommerce order ID. The handler requires the stored transaction ID to match `paymentId` and re-fetches the live payment status before applying anything; mismatched claims are ignored, and the request itself is not signed (see [How callback notifications are verified](/integration/web-plugins/woocommerce/configuration.md#how-callback-notifications-are-verified)). Responses: 200 on success, 400/405/500/503 with a JSON message otherwise. Logging: **WooCommerce → Status → Logs**, source `egw-checkout` (secrets are not logged). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/integration/web-plugins/woocommerce/order-lifecycle-and-operations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.