> 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/getting-started/information-for-existing-merchants.md).

# Information for Existing Merchants

## Moving to the New Payment Gateway

SEB is moving your existing ecommerce payment services to the **SEB Ecommerce Payment Gateway**.

Your existing Merchant Agreement with SEB remains in effect. The transition introduces a new payment platform, Merchant Portal, technical integration, and configuration model, but does not require you to start a new merchant onboarding process unless otherwise communicated by SEB.

This page highlights the key information you should know when moving from the existing payment gateway to the SEB Ecommerce Payment Gateway.

{% hint style="info" %}
This page contains migration-specific information for existing merchants.
{% endhint %}

For general information about the SEB Ecommerce Payment Gateway, Merchant Portal, Sandbox testing, payment methods, integrations, and API functionality, refer to the other sections of this Documentation Portal.&#x20;

We recommend starting with [**Quick Start**.](/getting-started/quickstart.md)

***

### Access to the New Payment Gateway

SEB will register your merchant and applicable Shops in the new **SEB Ecommerce Payment Gateway** as part of the migration process.

When your account is ready, you will receive an **invitation email** with instructions for activating your access to the SEB Merchant Portal.

After activating your account, you can access the Merchant Portal at:

[**https://portal.ecommerce.seb.ee**](https://portal.ecommerce.seb.ee/)

{% hint style="info" %}
The same Merchant Portal will be used for both Sandbox and Production functionality.
{% endhint %}

***

### Initial Sandbox Access

During the migration and integration phase, you will initially have access to [**Sandbox Mode**](/guides/sandbox/using-sandbox-mode.md).

After signing in to the Merchant Portal for the first time, you will be in Sandbox Mode by default.

Use Sandbox Mode to:

* Review your merchant and Shop configuration.
* Obtain Sandbox API credentials.
* Update and test your integration with the new Merchant API.
* Test the payment methods enabled for your Sandbox Shop.
* Validate payment statuses and callback handling.
* Test refunds and other applicable payment operations.
* Explore Hosted Checkout and other enabled functionality.
* Review test transactions in **Orders**.

Sandbox transactions are simulated and have no financial effect.

{% hint style="info" %}
Do not use Sandbox credentials or endpoints for live payment processing.
{% endhint %}

{% hint style="success" %}
SEB will communicate when your Production setup is available and provide information about the applicable migration and go-live schedule.
{% endhint %}

***

### Before You Start

After receiving access to the new Payment Gateway, we recommend that you:

1. Activate your Merchant Portal account.
2. Review **Quick Start** in this Documentation Portal.
3. Review your business and Shop configuration in Sandbox Mode.
4. Confirm that the expected payment methods and services are available.
5. Identify the changes required for your existing integration.
6. Obtain the API credentials for your Sandbox Shop.
7. Update and test your integration.
8. Follow the migration schedule communicated by SEB for the transition to Production.

***

## Understanding the New Structure

The SEB Ecommerce Payment Gateway uses a different merchant and payment-processing configuration model from the existing gateway.

Understanding **Shop** and **Shop Profile** will help you map your existing setup to EGW.

### Shop

A **Shop** represents a website, brand, or other online sales channel that accepts payments.

A Shop has its own configuration, which may include:

* Payment methods and services.
* Currencies.
* Technical integration settings.
* API credentials.
* Settlement account.
* Payment authorization and capture settings.

A merchant can have more than one Shop, for example separate Shops for different websites, brands, or sales channels.

You can review the configuration of your Shops in the **SEB Merchant Portal**.

***

### Shop Profile

A **Shop Profile** contains specific processing settings that can be applied to transactions from a Shop.

Profiles can be used when the same Shop requires different processing behaviour for different types of transactions.

Depending on your setup, these settings may include:

* Processing parameters.
* Transaction limits.
* Authorization model.
* Capture behaviour.

Your integration can refer to the applicable Shop Profile when initiating a transaction.

If no Shop Profile is specified, the Shop's default configuration applies. Where a Shop Profile is specified, the applicable profile settings are used.

{% hint style="info" %}
In simple terms:

**Shop** = where you accept payments.

**Shop Profile** = how a particular payment from that Shop should be processed.
{% endhint %}

{% hint style="warning" %}
**Not yet available**

This functionality is not yet available for merchant use. SEB will communicate when it becomes available.
{% endhint %}

***

## How This Differs from EveryPay

In EveryPay, a **Processing Account** defines how transactions are processed and can contain settings such as authorization type, 3-D Secure configuration, available payment methods, and capture behaviour.

EGW uses a different configuration model.

| Existing EveryPay setup  | SEB Ecommerce Payment Gateway                          |
| ------------------------ | ------------------------------------------------------ |
| Merchant configuration   | Merchant Agreement                                     |
| Shop / payment setup     | Shop Agreement                                         |
| Processing Account       | Shop configuration and, where applicable, Shop Profile |
| EveryPay API credentials | Shop-specific API credentials                          |
| EveryPay API             | Merchant API                                           |

{% hint style="info" %}
A **Shop Profile is not necessarily a one-to-one replacement for an EveryPay Processing Account**.

Some processing settings are configured directly for the Shop, while a Shop Profile is used where particular transactions require different processing behaviour.
{% endhint %}

SEB will configure your new setup according to the services and processing requirements applicable to your merchant account.

If you are unsure which Shop or Shop Profile should be used for a particular payment flow, contact SEB before changing your integration.

***

## Your Technical Integration Will Change

Moving to new Payment Gateway requires changes to your technical integration.

The **SEB Ecommerce Payment Gateway Merchant API** is different from the existing EveryPay API and uses **OAuth 2.0** for API authentication.

Each Shop has its own:

* **API Client ID**
* **API Client Secret**

You can find the Sandbox credentials for the selected Shop in the Merchant Portal under:

**Settings → Shop Settings → Technical Information**

Your backend uses these credentials to authenticate with the Merchant API.

{% hint style="warning" %}
Keep your **API Client Secret** confidential.

Do not expose it in browser-based code, mobile applications, public repositories, application logs, or other client-accessible locations.
{% endhint %}

For implementation guidance, see [**Integrations**](/integration/merchant-api.md) and the [**Merchant API Reference**.](/api-reference/merchant-api.md)

***

## Review Your New Setup

After receiving access to the Merchant Portal, review the configuration prepared for your business.

Confirm that:

* Your business information is correct.
* All required Shops are available.
* Shop information is correct.
* The required payment methods and services are enabled.
* The required currencies are available.
* Your settlement account and applicable payment settings are correct.
* Your integration uses the credentials belonging to the correct Shop.
* Where applicable, transactions use the required Shop Profile.
* Your Home URL and Callback URL are configured correctly.

If something does not match your agreed setup, contact SEB before moving to Production.

***

## Test Your Integration

Use **Sandbox Mode** to update and validate your integration before processing live transactions through EGW.

Test the payment methods, customer journeys, and payment operations relevant to your business.

At minimum, verify that:

* Successful payments are handled correctly.
* Failed and declined payments are handled correctly.
* Customer cancellations and abandoned payment journeys are handled correctly.
* Payment statuses update your orders correctly.
* Callback notifications are received and processed correctly.
* Payment amounts and currencies are correct.
* Customer return and redirect handling works as expected.
* Refunds and other applicable payment operations work correctly.
* Your system stores the Payment ID and can match it with the corresponding order.

Use **Test Data** and **Test Scenarios** for detailed Sandbox testing guidance.

{% hint style="info" %}
Testing and validation of your integration are your responsibility.

Do not use the customer browser return alone to determine whether a payment has completed. Use the confirmed gateway **payment status** as the source of truth.
{% endhint %}

***

## Prepare for Production

Sandbox and Production are separate environments.

SEB will communicate when your Production setup is available and provide information about the applicable migration and go-live schedule.

Before processing live transactions:

* Review your Production Shop configuration.
* Obtain the API credentials for your Production Shop.
* Configure your application to use the Production endpoints and credentials.
* Verify your Production Home URL and Callback URL.
* Confirm that the required payment methods and services are available.
* Review your Hosted Checkout configuration, where applicable.
* Confirm that your payment and order-management logic is ready for live processing.
* Ensure that Sandbox credentials and endpoints are not used in Production.

{% hint style="info" %}
Sandbox configuration, credentials, and transaction data are not automatically transferred to Production. Review your Production configuration separately before going live.
{% endhint %}

***

## After Moving to SEB Ecommerce Payment Gateway

When you begin processing live payments through the new Payment Gateway, closely monitor your first transactions.

Verify that:

* Payments reach the expected final statuses.
* Callback notifications are received and processed.
* Orders are updated correctly.
* Payment amounts and currencies match your orders.
* Transactions can be located in **Merchant Portal → Orders**.
* Refunds and other required payment operations work as expected.

Continue monitoring and reconciling payments as part of your normal operational processes.

***

## Need Help?

If you have questions during the transition:

1. Review the relevant topic in this **Documentation Portal**.
2. Ask the **AI Assistant** <button type="button" class="button primary" data-action="ask" data-icon="gitbook-assistant">Ask a question…</button> available in the Documentation Portal.
3. If the documentation and AI Assistant do not resolve your question, contact **SEB**.

For questions about your Merchant Agreement, Shop configuration, enabled services, or migration schedule, contact your SEB representative.

&#x20;


---

# 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/getting-started/information-for-existing-merchants.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.