> 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/testing-and-go-live.md). # Testing & go-live End-to-end test flow and go-live checklist for the SEB E-commerce Payment Gateway plugin for WooCommerce ## Test in Sandbox Prerequisites: plugin [configured](/integration/web-plugins/woocommerce/configuration.md) with Environment = *Sandbox*, sandbox credentials entered, callback URL registered in the Merchant Portal at . For test cards and magic values, see [Sandbox test data](/guides/sandbox.md). The end-to-end test script — run the steps in order: 1. **Place an order.** In your storefront, add a product to the cart, check out, select *Online Payment*. You are redirected to the SEB E-commerce Payment Gateway payment page. 2. **Pay with a test card.** If the payment page offers more than one payment method, select the card option (labelled *Credit/Debit*) and choose *Enter card manually* rather than logging into a wallet. Use the card number for successful authorization, any cardholder name, any valid future expiry date (e.g. 12/28) and any 3-digit CVV (e.g. 123). Approve the 3D Secure test challenge when it appears. You are returned to your store's order-received page. 3. **Verify the order.** In **WooCommerce → Orders** the order shows *On hold* — or *Processing*, if your shop captures immediately rather than authorizing first. The order notes show the payment progression, and the transaction ID matches the payment in the Merchant Portal. 4. **Verify the callback.** The status change in step 3 happens even when the customer never returns to your store. Repeat the test and close the browser on the payment page instead of returning; the order must still reach *On hold* (or *Processing*) within a few minutes. If it doesn't, your callback URL isn't reachable ([Configuration](/integration/web-plugins/woocommerce/configuration.md)). 5. **Capture** (pre-authorization shops only): capture the payment in the Merchant Portal and confirm the order moves to *Processing*. 6. **Fail one on purpose.** Place another order and either cancel on the payment page, or pay with the test card for declined authorization, which always fails authorization. The order must show *Cancelled* and you must land back at checkout with an error message. ![The storefront checkout with Online Payment selected (classic checkout), and beside it the WooCommerce → Orders list after step 3 showing the order in On hold.](https://1157570179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBDtfypkI85zidcVwaDj%2Fuploads%2FgyJcMcwzeiulWQpqVptQ%2Fwc-checkout-and-orders.png?alt=media) When all six steps pass, continue with the go-live checklist. ## Go-live checklist * [ ] Sandbox script above fully passed * [ ] Live OAuth2 Client ID + Secret obtained from the Merchant Portal → **Settings → Shop Settings → Technical Information** * [ ] Plugin **Environment** switched to *Live*, live credentials saved * [ ] Callback URL registered for the **live** shop configuration in the Merchant Portal * [ ] Title/Description reviewed in all shop languages * [ ] One real low-value order placed, paid, and verified reaching *On hold* or *Processing*, matching how your shop captures * [ ] Store cache/firewall confirmed not to block or cache the callback URL Problems at any step: collect plugin version, WooCommerce/WordPress versions, order ID, transaction ID, and the relevant lines from **WooCommerce → Status → Logs** (source `egw-checkout`), and contact SEB support. --- # 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/testing-and-go-live.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.