> 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/prestashop/order-lifecycle-and-operations.md).

# Order lifecycle & Operations

How the SEB E-commerce Payment Gateway module for PrestaShop handles orders, order states, and day-to-day operations

## How order states change

Two paths update an order after payment: the customer returning to your shop, and the authoritative server-to-server **callback notification**. Neither path trusts the message it receives — both re-check the real payment status with the gateway before changing anything ([how this is verified](/integration/web-plugins/prestashop/configuration.md#how-callback-notifications-are-verified)).

| Payment status at the gateway     | PrestaShop order state                                      | What it means                                                                                                                                          |
| --------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Payment page opened, not finished | **Awaiting payment confirmation** (installed by the module) | Order created; waiting for the customer to pay                                                                                                         |
| Sent for processing / Authorized  | **Awaiting payment capture** (installed by the module)      | Money reserved, not captured. Capture in the Merchant Portal; the order then moves on automatically                                                    |
| Captured / Settled                | **Payment accepted**                                        | Paid — standard PrestaShop behavior follows (emails, invoice per your shop settings). The gateway payment ID is recorded as the order's transaction ID |
| Cancelled / Abandoned / Failed    | **Canceled**                                                | The customer's cart is restored so they can retry                                                                                                      |

Notes for merchants:

* Orders sitting in **Awaiting payment confirmation** for more than a few minutes are almost always abandoned payment pages. They cancel themselves once the gateway reports the outcome; you do not need to act.
* **Awaiting payment capture** is your to-do signal for pre-authorization shops: capture in the Merchant Portal (<https://merchantportal.ecommerce.sebgroup.com>).

![A paid SEB E-commerce Payment Gateway order in the back office order view, showing the state history — Awaiting payment confirmation → Awaiting payment capture → Payment accepted, once captured — and the transaction ID on the payment block.](https://1157570179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBDtfypkI85zidcVwaDj%2Fuploads%2FyXXse09sCG85QbfCTW2f%2Fps-order-detail-payment-accepted.png?alt=media)

## What you do where

| Task                               | Where                                                                                                                                                          |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| See payment state / transaction ID | Back office order view (state history; transaction ID on the payment block once paid)                                                                          |
| Capture a pre-authorized payment   | Merchant Portal                                                                                                                                                |
| Issue a refund                     | Merchant Portal — the back office has no refund/credit-slip action for this payment method; the order state updates automatically once the gateway confirms it |
| Reconciliation                     | Merchant Portal; match via transaction ID                                                                                                                      |

## Edge cases

* **Callback never arrives:** orders stall in *Awaiting…* states although payment progressed. Fix the callback registration ([Configuration](/integration/web-plugins/prestashop/configuration.md)); no scheduled re-check exists.
* **Duplicate notifications** are recognized and ignored safely.
* **Customer pays but never returns:** the callback still completes the order.
* **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/prestashop/configuration.md#saved-cards).

## For developers

Callback endpoint: `POST https://your-shop.example/module/egwcheckout/callback`, JSON `{type, paymentId, merchantReference, paymentStatus}`; `merchantReference` is the PrestaShop order ID. The handler requires the stored payment ID to match and re-fetches the live status before applying anything; the request itself is not signed (see [How callback notifications are verified](/integration/web-plugins/prestashop/configuration.md#how-callback-notifications-are-verified)). Logs: **Advanced Parameters → Logs**. Return route: `/module/egwcheckout/redirect`. The module keeps its order↔payment link in the `egw_checkout_payment` table until the order is finalized.


---

# 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/prestashop/order-lifecycle-and-operations.md?ask=<question>&goal=<user_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.