> 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/guides/merchant-portal/monitor-your-business/orders.md). # Orders Orders is where you review and manage payments processed through the Payment Gateway. Use it to find a specific payment, check its current status and history, investigate unsuccessful transactions, and perform supported payment operations such as capture or refund. The information and actions available for an order depend on the payment method, transaction status, shop configuration, your Merchant Agreement, and your user permissions. *** ### Find a payment You can search and filter Orders using transaction and order information available to your merchant account. Depending on the available order data, you can narrow the results using the following filters: * date range * shop * last 4 digits of the card or IBAN * Order No * Invoice No * payment status * payment method * fraudulent transactions * amount or amount range * customer full name * customer email * Payment Link ID For card payments, you may also be able to search using the last four digits of the card number. Sensitive card information, such as the full card number or CVV/CVC, is never displayed in the Merchant Portal.
{% hint style="info" %} Use the most specific identifier available when investigating an individual payment. A **Payment ID** is particularly useful because it uniquely identifies a payment throughout its lifecycle. {% endhint %} {% hint style="info" %} The underlying Portal supports search across date, shop, method, status, amount, payment references, masked instruments, and recurring-payment indicators. {% endhint %} *** #### Transaction history period The *Orders* section provides access to transaction data for the **past 12 months**. The maximum date range that can be selected for a single search is **one month**. To review transactions covering a longer period, you should perform several separate searches, each covering no more than one month. **Example:** In September 2026, transaction data is available starting from September 2025. #### Export Transaction data displayed in the *Orders* section can be exported in **CSV format**. *** ### Review payment details Open an order when you need more information than is available in the Orders list. The detailed view brings together information about the payment and its processing history. Depending on the payment method and transaction flow, this can include: * current payment status * amount and currency * payment method * timestamps * payment and order references * authorization and capture information * refunds or reversals * recurring or subscription association * additional payment or customer information available for the transaction This helps you understand how the payment progressed and whether any follow-up action is required.
For definitions of individual payment states and their lifecycle, see [**Payment Statuses**](/payment-methods/cards/payment-statuses.md). *** ### Manage transactions For eligible transactions, you can perform payment operations directly from the order details. The actions available depend on the current transaction state and the payment method. An action is only available when it is valid for that transaction. * **Capture** - collect funds from a previously authorized payment when the order is ready to be fulfilled. * **Refund** - return funds after a payment has been completed. Partial refunds may be supported where configured. * **Cancel Order**- cancel an authorization before settlement and release the reserved amount. #### Capture an authorized payment If your shop uses pre-authorization, a successful authorization reserves funds but does not collect them immediately. When the order is ready to be fulfilled, you can **capture** the authorized payment to collect the funds. Depending on your configuration, partial or multiple captures may also be supported. The existing payment documentation defines Capture as collecting funds from a previously authorized transaction and notes that partial or multiple capture can depend on merchant configuration. {% hint style="warning" %} Capture a payment only when you are ready to fulfil the related order or service. {% endhint %} For more information about authorization and capture flows, see [**Supported Operations**](/payment-methods/cards/supported-operations.md) for Card payments and [**Payment Processing**](/payment-methods/pay-by-bank/payment-processing.md) for Pay by Bank transactions. #### Refund a completed payment Use a **refund** when you need to return funds after a payment has been completed. For card payments, the Payment Gateway supports full and partial refunds. Multiple partial refunds may be possible as long as the total refunded amount does not exceed the amount originally captured. Refund availability for other payment methods may differ and depends on the underlying payment method and provider capabilities. A refund is a new payment operation associated with the original transaction. Its processing may therefore have its own status and may not be completed immediately. For detailed refund behaviour, see [**Refunds**](/features/refunds.md). #### Cancel or reverse an authorization If an authorized card payment should no longer be completed, a **reversal (void)** may be available before settlement. A reversal releases the amount that was reserved during authorization instead of collecting and then refunding it. Typical reasons include a cancelled order, an order that cannot be fulfilled, a duplicate authorization, or an incorrect amount. Where possible, use a reversal for an authorization that should not be completed and use a refund for funds that have already been captured. *** ### Understand what requires attention The payment status helps you decide whether an order needs action. For example: * an **Authorized** card payment may require capture when pre-authorization is used * a **Captured** card payment has been successfully collected * a **Settled** payment has completed its settlement lifecycle * **Failed**, **Cancelled**, or **Abandoned** payments were not successfully completed * a **Refunded** payment has had some or all of its captured amount returned Not every payment method uses the same statuses. For example, account-to-account payments do not follow the same authorization and capture lifecycle as card payments. For the full lifecycle and guidance on each status, see [**Payment Statuses**](/payment-methods/cards/payment-statuses.md) for Cards transactions and [**Payment Statuses**](/payment-methods/pay-by-bank/payment-statuses.md) for Pay by Bank payments**.** *** ### Investigate unsuccessful payments Orders is also the starting point when a customer reports that a payment did not complete as expected. Review the transaction details to determine: * which payment method was used * the latest status known to the Payment Gateway * when the payment was initiated and last updated * whether the payment reached authorization or another processing stage * whether a refund, reversal, or other operation has already been initiated * which payment and order references can be used for further investigation A failed or incomplete payment does not always indicate a technical problem with the Payment Gateway. The outcome may also depend on an issuer, bank, payment provider, customer authentication, or another external participant in the payment flow. If you need to determine whether there is a wider service issue, check the [**Status Page**](/guides/status-page.md). *** ### Export transaction data You can export Order data in a structured format for operational analysis or reconciliation, subject to your permissions. Exports are useful when you need to: * compare payments with your own order records * investigate a group of transactions * perform operational reconciliation * analyse transaction activity outside the Merchant Portal Exported transaction data is intended for operational use and does not replace official settlement files or acquiring statements. {% hint style="warning" %} Orders is separated between Sandbox and Live — see "[Sandbox and Live are separate environments](/guides/merchant-portal.md)" {% endhint %} *** ### Frequently Asked Questions
Why can't I see the Capture option? Capture is available only for payments that use a pre-authorization flow and are currently in a state that can be captured. Availability can also depend on your shop configuration and permissions.
Why can't I refund a payment? Refunds are only available for eligible transactions. Availability depends on the payment method, current payment state, remaining refundable amount, and your configuration and permissions. If previous partial refunds have already been processed, the amount still available for refund may be lower than the original payment amount.
Should I cancel a payment or refund it? Use a **reversal or cancellation** when an authorized payment has not yet been completed and the reserved funds should be released. Use a **refund** when funds have already been captured and need to be returned to the customer.
Why is a refund not visible to the customer immediately? Submitting a refund does not necessarily mean the funds are immediately available in the customer's account. The refund must be processed through the relevant acquiring, scheme, or payment-provider infrastructure. Check the refund status in the payment details rather than assuming that submission means completion.
Can I use Orders for reconciliation? Yes, Orders and exported transaction data can support operational reconciliation. For formal financial reconciliation, use the relevant settlement reports, acquiring statements, or other official reconciliation files.
--- # 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/guides/merchant-portal/monitor-your-business/orders.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.