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

# Order lifecycle & Operations

How the SEB E-commerce Payment Gateway module for Magento 2 handles orders, invoices, emails, and day-to-day operations

## How orders, invoices and emails behave

Two paths update an order after payment: the customer returning to your store, 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/magento-2/configuration.md#how-callback-notifications-are-verified)).

The module also changes Magento's email behavior deliberately: the order confirmation email is **not** sent at order placement — it is sent when the payment is confirmed. This prevents confirmation emails for orders whose payment never completes.

| Payment status at the gateway     | What happens in Magento                                                                                          |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Payment page opened, not finished | Order exists, pending; no email sent yet                                                                         |
| Sent for processing / Authorized  | Order confirmed: order email sent, **invoice created (not captured)**. Capture in the Merchant Portal when ready |
| Captured / Settled                | **Invoice captured**, invoice email sent — the order is paid                                                     |
| Cancelled / Abandoned / Failed    | Order **canceled**, the customer's cart is restored so they can retry                                            |

Notes for merchants:

* **Pre-authorization shops:** "invoice created, not captured" means money is reserved. Capture in the Merchant Portal (<https://merchantportal.ecommerce.sebgroup.com>); the module captures the Magento invoice and sends the invoice email automatically.
* **You never need to invoice manually** — the module creates and captures invoices as the payment progresses.
* If a customer reports paying but the order looks unpaid, check the Merchant Portal before anything else (see edge cases).

![A paid SEB E-commerce Payment Gateway order in Sales → Orders → order view: Order Status "Processing" on the Information tab, and one "Paid" invoice on the Invoices tab.](https://1157570179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBDtfypkI85zidcVwaDj%2Fuploads%2FZsjDgzbywRczxJRFcmpj%2Fm2-order-processing-and-invoice.png?alt=media)

## What you do where

| Task                             | Where                                                                                                                                                           |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| See payment status               | Magento order view → Information tab, *Order Status*                                                                                                            |
| See the gateway payment ID       | Not shown in the Magento admin UI — reconcile via the Merchant Portal (match by amount/timestamp), or ask support to look it up by order ID                     |
| Capture a pre-authorized payment | Merchant Portal (Magento invoice captures automatically)                                                                                                        |
| Issue a refund                   | Merchant Portal — the module has no credit-memo action for this payment method; the invoice and order update automatically once the gateway confirms the refund |
| Reconciliation                   | Merchant Portal; match orders by amount and timestamp (no payment ID is displayed on the order)                                                                 |

## Edge cases

* **Slow payment confirmation:** if the gateway needs longer than usual to confirm a payment, the return page keeps the customer informed that the payment is still being confirmed instead of reporting a failure; the order is completed by the callback as soon as confirmation arrives.
* **Callback never arrives:** orders stay unconfirmed although payment progressed. Fix the callback registration, then re-trigger the notification or contact SEB support. No scheduled re-check exists.
* **Duplicate notifications** are recognized and ignored safely.
* **A saved card is no longer accepted** by the gateway: the customer sees a message to pay with a new card instead, the order is cancelled like any failed payment, and the card is removed from their stored payment methods. See [Saved cards](/integration/web-plugins/magento-2/configuration.md#saved-cards).

## For developers

Callback endpoint: `POST /rest/V1/egw/payment/status` (anonymous REST route) with JSON `{type, paymentId, merchantReference, paymentStatus}`. **`merchantReference` is the order-payment entity ID**, not the order increment 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/magento-2/configuration.md#how-callback-notifications-are-verified)). Module log: `var/log/egw_checkout/app.log` (info/error split; secrets not logged). Frontend return route: `egw/customer/returnurl`; status poll route: `egw/customer/payment`.


---

# 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/magento-2/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.