Migrating from RPG & SecurePay

This section is for partners and platforms that take payments on behalf of merchants through Teya's legacy online payments platform — RPG (Borgun Payment API), SecurePay, B-Gateway or the Ticket API — and need to move those merchants to the new platform. It explains what is changing, the order to do things in, and which guide applies to each of your integrations.

```admonition icon: fas fa-store title: Migrating your own business, not other merchants? content: If you built the integration for your own website, the Businesses section has the same guides written for a single store. link: /online-payments/migration/overview ```

What is changing

Teya's legacy online payment systems — SecurePay, the RPG payment API, the B-Gateway web service and the Ticket API — continue to work as normal today. Onboarding new merchants to them will stop soon, and they will be retired in early 2027. Every integration still on them needs to be moved to the new Teya online payments platform before then.

The new platform is live and processing payments across Teya's markets. It replaces per-request signatures with OAuth credentials, browser-side confirmations with signed webhooks, and self-built 3D Secure with authentication that is handled for you. Everything you build for one merchant works for all of them — only the credentials differ.

The migration in three stages

Migrating a merchant base is not one switch. Do it in this order, and each stage de-risks the next.

1 Build and test a fresh integration

2 Verify it with one merchant

3 Migrate existing merchants and stored cards

1. Build and test a fresh integration

Integrate with the new platform as if you were a new partner, using a staging partner account and development stores from your Teya partner contact. Nothing on the legacy platform changes while you do this, and you need no merchant credentials yet. Cover every flow your merchants use today — checkout, refunds, payment status, and stored-card charging if you offer it — and test each with test cards in staging.

Start from the partner overview to choose the integration: Embedded Components for most RPG and B-Gateway integrations, Hosted Checkout for redirect-style SecurePay flows, Pay By Link for Ticket API flows.
Use the migration guides below for the differences — what replaces what, and the traps a legacy integration falls into.

2. Verify it with one merchant

Before touching your existing base, prove the integration end to end in production with a single store: either onboard a new merchant through the registration flow, or migrate one existing merchant using the credentials route below. Run real payments, a refund, and confirm the webhook arrives and verifies. Keep that merchant's legacy integration available for a day or two in case you need to roll back.

3. Migrate existing merchants and stored cards

With one merchant live, the rest is repetition: obtain credentials for each store, switch its traffic, verify, and retire its legacy credentials. Stored cards and recurring payments are migrated last, on their own track, once every merchant's new-card flow is already on the new platform — see the stored cards and recurring guide.

```admonition icon: fas fa-robot title: Building with an AI coding assistant? content: Migrate with an AI assistant has ready-made prompts for stage 1 (inventory your legacy integration and build the new one), the per-store credentials step, stored cards, and raising questions with Teya — plus a single downloadable file containing this whole section for the assistant to read. Worth a look before you start; it can save your team a lot of time. ```

Credentials for existing merchants

On the new platform every store has its own OAuth client credentials, issued to you when the merchant is registered on your platform. For merchants you already serve, you don't want to ask each one to re-onboard:

Your merchants today use	How you get their new credentials
RPG (you hold each merchant's private key)	Exchange the RPG key for a Client ID and Client Secret, one call per store. No merchant involvement.
SecurePay (you post to SecurePay with each merchant's gateway ID)	Register each merchant through the registration flow — the merchant approves once from their Teya account. To migrate a large merchant base, talk to your Teya partner contact about the approach.
B-Gateway (you hold a username, password and `MerchantID` per merchant)	Register each merchant through the registration flow. If you hold B-Gateway credentials for many merchants, talk to your Teya partner contact about the approach.
Your own Teya credentials only (a single legacy merchant account)	You are a merchant for this purpose — see the Businesses migration section.

```admonition icon: fas fa-key title: One set of credentials per store content: Credentials are never shared across merchants. Store each merchant's client_id, client_secret, store_id and webhook public key against that merchant, exactly as you do for merchants registered through the standard flow. ```

Which guide applies to you

Most platforms have more than one legacy integration. Take each row that applies and follow its guide; they share the same structure and the same credentials.

Legacy integration	Typical signs in your code	Migrate to	Guide
RPG payment API	Calls to `/api/payment`, `/api/mpi/v2/…`; a private key per merchant; your own 3D Secure handling	Embedded Components (or the direct API where components have no equivalent)	RPG → Embedded Components
B-Gateway web service	SOAP/XML requests such as `getAuthorization` to `gateway01.borgun.is`; a username, password and `MerchantID` per merchant; card numbers reach your servers	Embedded Components (Hosted Checkout as an alternative)	B-Gateway → Embedded Components
SecurePay redirect	A form posted to `securepay.borgun.is` with a `checkhash`; customers pay on a Teya-hosted page	Hosted Checkout	SecurePay → Hosted Checkout
SecurePay embedded	`displaymode=iframe`; the payment form sits inside your checkout page	Embedded Components	SecurePay → Embedded Components
Ticket API	Payment URLs created in advance and sent to customers	Pay By Link	Ticket API → Payment Links
Stored cards / recurring	Multi-use tokens (`tm_…`) or virtual card numbers (`991001…`) charged without the customer present	Card on File	Stored cards & recurring

```admonition icon: fas fa-plug title: Do you maintain a plugin for an ecommerce platform? content: If your merchants install your plugin (WooCommerce, OpenCart, Magento, PrestaShop …) rather than integrating with you as a service, the same guides apply to the plugin's code, and each merchant's credentials arrive through the registration flow when they connect. Tell your Teya partner contact which platform you build for so a plugin_type can be assigned. ```

Migration guides

Each guide starts with a short, non-technical summary you can forward to a merchant or a product owner, followed by the developer guide: how it works before and after, a table of what replaces what, and the migration steps with the one request you need at each.

RPG → Embedded Components

For direct RPG API integrations

Replace /api/payment and your MPI calls with a checkout session and a component; 3D Secure and Apple Pay are handled for you.

B-Gateway → Embedded Components

For SOAP/XML B-Gateway integrations

Replace getAuthorization, your card form and any 3D Secure flow with a checkout session and the Checkout component; save cards for subscriptions and charge them by API.

SecurePay → Hosted Checkout

For redirect-style SecurePay integrations

The like-for-like path: one server-side call replaces the signed form post, and the customer still pays on a Teya page.

SecurePay → Embedded Components

For iframe integrations, or to upgrade the checkout

Keep the payment form on your page. Includes a comparison to help you choose between Hosted Checkout and Embedded Components.

Ticket API → Payment Links

For pre-created payment URLs

Create links by API or in the Business Portal, get paid by webhook.

Stored cards & recurring

Cross-path: do this last

Stop creating legacy tokens, run both platforms side by side, then let each legacy token convert itself on first use. No customer re-enters a card.

Reference: what replaces what

Migrating from RPG - Every RPG endpoint and its replacement on the new platform
Migrating from SecurePay - Every SecurePay form parameter and its replacement
Migrating from B-Gateway - Every B-Gateway operation and field and its replacement
RPG Credentials Migration - The credential exchange API

Whichever path you take

Test first. Every guide rehearses the full flow in staging with test cards before any real traffic moves.

Nothing switches until you switch it. Legacy integrations keep working in parallel while you build, and for a safety window after each merchant moves.

Migrate one-off payments before stored cards. The stored-card migration assumes each merchant's new-card flow is already on the new platform.

Start early. The work is the same in early 2027 as it is now; doing it now means doing it calmly, with support.

```admonition icon: fas fa-life-ring title: Need help? content: Your Teya partner contact can provision staging accounts and development stores, agree the credentials route for your merchant base, and plan the stored-card import. For integration questions, see Support. ```

Next steps

Partner overview - Choose your integration and set up your partner account
Register Your Merchants - The registration flow and credential model
RPG Credentials Migration - Exchange RPG keys for new credentials
Testing - Test cards and integration checklist
Migrate with an AI assistant - Prompts and a downloadable pack for LLM-assisted migrations
Migration FAQ - Timelines, merchant-base questions, what is different
API Reference - Full API endpoint documentation