Before you start

When exactly will the legacy platform stop working?

SecurePay, the RPG payment API, the B-Gateway web service and the Ticket API keep working as normal today. Onboarding to them stops soon, and they are retired in early 2027. You will be given notice before anything changes for your customers, and your Teya contact can tell you where you stand at any time.

What happens if I do nothing?

Any merchant still routed through your legacy integration when the platform is retired will stop being able to take payments through your platform. Teya will contact merchants directly about the retirement, so merchants will also be asking you what your plan is.

We will contact you before your integration is affected — but don't wait for that: the work is the same now as later, and now is calmer.

Does migrating cost anything, and does my pricing change?

There is no Teya fee for migrating, and your pricing agreement with Teya is unchanged — it is not tied to which platform your integration uses. The only prerequisite is that Teya online payments are enabled on your store, which your Teya contact arranges.

How long does it take?

It depends on the path. A SecurePay redirect integration moving to Hosted Checkout is a small development project — days including testing, not weeks. Embedded Components and RPG integrations are a little more, mainly frontend work. B-Gateway integrations are a small development project too, and end with less code than you have today. Ticket API users often need no development at all. Stored cards and recurring payments are a separate, phased track that runs alongside normal billing cycles — see the stored cards guide.

Do I need a new merchant account, contract or credentials?

Your Teya merchant account and settlement stay the same. What changes is how your integration authenticates: instead of a SecurePay secret key, an RPG private key or B-Gateway credentials, each store gets OAuth API credentials (a Client ID and Client Secret). For merchants you already serve on RPG you exchange the existing key; for others, credentials arrive through the registration flow — see credentials for existing merchants. Your store needs Teya's online payments enabled; if credential creation reports that no compatible store was found, ask your Teya contact.

I don't know whether I'm on SecurePay, RPG or B-Gateway. How do I find out?

Ask whoever built your site where the customer types their card number. A Teya/Borgun page means SecurePay redirect; a frame inside your page means SecurePay embedded; your own form means a direct API. For a direct API, check what your server sends to borgun.is: JSON to /api/payment is RPG, XML such as getAuthorization to gateway01.borgun.is is B-Gateway. The overview turns the answers into a guide. If nobody knows, your Teya contact can look up how your payments arrive today.

During the migration

Can I run the old and new integrations in parallel?

Yes, and the guides recommend it: keep the legacy integration live for a day or two after you switch, so rolling back is a configuration change. Both settle to the same merchant account. There is no time limit on parallel running before the retirement date.

How do I test without touching live payments?

Everything is rehearsed in Teya's staging environment with a development store and test cards, including 3D Secure challenges, declines, refunds and webhooks. Nothing reaches your production account until you create production credentials and switch hosts.

Will my customers notice anything?

On Hosted Checkout the experience is the same shape as SecurePay: click Pay, enter the card on a Teya page, come back. Differences they may notice are improvements — a declined card lets them try another instead of ending the checkout, Apple Pay appears where the device supports it, and foreign cardholders may be offered to pay in their own currency. With Embedded Components the card fields sit inside your own checkout, so the visible change is that they no longer leave your site.

What about 3D Secure? I built my own MPI integration.

You delete it. Authentication runs automatically inside Hosted Checkout and the Embedded Components — enrollment, the bank challenge and validation are handled for you, with no separate calls and nothing to certify. The only place you still see 3D Secure explicitly is customer-present charges on saved cards through the direct API, where a challenge may be returned for you to display.

This also applies if you run 3D Secure through B-Gateway's get3DSAuthentication or a third-party 3D Secure provider: the connection is no longer needed. On the new platform every customer-present payment goes through 3D Secure, and charges without the customer are made on a card they saved with you, as merchant-initiated payments. See the B-Gateway guide.

After you switch

Can I still refund payments that were taken on SecurePay, RPG or B-Gateway?

Yes. Refund legacy transactions in B-Online exactly as you do today — it keeps working alongside your new integration and stays available until the legacy platform is retired. Refunds of payments taken on the new platform are made in the Business Portal or by API. Your legacy transactions are also visible in the Business Portal, and stay there.

Will I still be able to see my old transactions and reports?

Yes. Your legacy reporting stays available, read-only, until the legacy platform is retired. Your legacy transactions are also visible in the Teya Business Portal and remain there indefinitely, alongside new-platform payments — which appear in the Portal from your first live transaction.

Our systems pull transaction and settlement data from B-Gateway. What replaces that?

B-Gateway's transaction list, settlement, chargeback, dispute and fraud reports have no one-to-one API replacement. For a single payment, look up its checkout session by ID; for everything else, use the Business Portal. There are no batches on the new platform, so batch numbers disappear from your records: key them on the transaction_id instead. If a finance or reconciliation system depends on these reports, contact Teya support with your specific case before you migrate so we can check it with you. Each report is listed on the B-Gateway reference.

Do my customers' saved cards survive the move?

Yes. Nobody re-enters a card: Teya imports your stored cards, and each legacy token upgrades itself the first time you charge it on the new platform. The order of steps matters — read the stored cards & recurring guide before changing anything about how cards are saved.

This includes virtual card numbers from B-Gateway's getVirtualCard.

What happens to my old credentials and settings?

Once your parallel-running window is over, remove the legacy code; Teya retires the old SecurePay, RPG or B-Gateway credentials for you — nothing to request. Branding settings do not carry over: logo, checkout and receipt messages and legal URLs are configured once per store in the Business Portal.

What about chargebacks and disputes on legacy transactions?

Disputes are handled against your merchant account, not the integration, so a chargeback on a payment taken through SecurePay is handled the same way after you migrate.

Evidence for legacy transactions remains retrievable — they stay visible in the Business Portal.

How do I reconcile orders across the two platforms?

Use merchant_reference for your order number, and keep writing your legacy order ID into metadata during the transition if your back office keys on it. Every new-platform payment has a transaction_id that appears in the webhook, the session lookup and the Business Portal — store it on the order.

What is different on the new platform

Why are amounts sent as integers?

Amounts are in the smallest unit of the currency: €54.43 is 5443, £9.99 is 999. ISK has no subunit, so 100 ISK is simply 100. This is the single most common bug in migrations from SecurePay, which took a decimal string.

Why is there no webhook for failed payments?

The platform sends a signed webhook for successful payments (payment.succeeded.v1). Failures and abandoned checkouts are covered by looking the session up by its ID, which also tells you whether a customer who never returned to your site did in fact pay. See Webhooks.

Where do I see payments, refunds and settlements now?

In the Business Portal (and the Teya app), alongside your in-store payments if you have Teya card machines. Refunds can be issued there without a developer.

Settlement does not change: same merchant account, same payout timing and statements. New-platform transactions simply appear in the Business Portal as well.

Do refunds, captures and cancellations work the same way?

Refunds are full or partial, and can be repeated up to the original amount. A payment is captured at most once per authorisation, and the remainder is released. There is no separate "cancel": a refund on an uncaptured payment reverses the authorisation. See Payment Actions.

Can I still take pre-authorisations?

Yes — and if you were on SecurePay this is new. Create the session with type PRE_AUTHORISATION and capture later, including a partial amount. Pre-authorisations are currently available for certain tourism-related business activities; if your business needs them for another use case, contact your Teya account manager.

Does currency conversion (DCC) still work?

Yes, automatically: when a cardholder's currency differs from the transaction currency, the checkout offers to pay in their own currency. There is nothing to implement. DCC is not offered on pre-authorisations.

Which currencies and languages are supported?

The same ISO currency codes as before (ISK, EUR, GBP, CZK, HUF, USD and others). HRK is no longer used; Croatia settles in EUR. The checkout language is auto-detected from the customer's browser or set per session with a BCP 47 code such as is-IS or cs-CZ.

Checkout languages include English, Icelandic, Czech, Slovak, Croatian and Hungarian, among others.

What is different about security and PCI?

Card data is entered on Teya-hosted pages or inside Teya-hosted iframes, so your systems never see it and you stay in the lightest PCI category (SAQ A). Per-request signatures (checkhash) are replaced by short-lived access tokens, and payment confirmations are RSA-signed webhooks you verify with a public key rather than a shared secret. Sending raw card data to Teya from your own servers is restricted to merchants with PCI DSS (SAQ D) evidence.

If you use B-Gateway today, card numbers pass through your own servers. Moving to Embedded Components or Hosted Checkout takes them out entirely, which is usually the biggest reduction in compliance work of any migration path.

I use other B-Gateway features. What happens to them?

Some B-Gateway features work differently on the new platform or depend on your set-up: batches (settlement is now automatic), partial reversals (capture the final amount on a pre-authorisation, or refund the difference), Dynamic Descriptors, invoice detail data (sendDetailData), passenger itinerary data, batch authorisations, and telephone, keyed (B-Online) or card-reader payments. If you use any of them, contact Teya support with your specific case before you migrate. The B-Gateway reference lists every operation and where it lives now.

Are the test cards the same?

No. Use the official list on the Testing page; it covers frictionless and challenge 3D Secure, declines and specific error cases.

Migrating a merchant base

How do I get credentials for merchants I already serve, without asking them to re-onboard?

For merchants on RPG: exchange each merchant's RPG private key for new credentials with one API call per store — see RPG Credentials Migration. For merchants on SecurePay: register each merchant through the registration flow, where the merchant approves the connection once from their Teya account. To migrate a large merchant base, talk to your Teya partner contact about the approach.

Can I migrate merchants gradually?

Yes. Credentials are per store and every merchant switches independently, so you can move a handful, verify, and continue. Keep the legacy route available per merchant for a short rollback window.

Who tells the merchants, and what do they need to do?

Teya notifies every legacy merchant directly about the retirement. The preparation is managed by you; merchants may need to reconnect their store or approve the connection between your platform and their Teya account when the switch happens, so tell them what to expect. You know your merchants and your migration plan, so you decide how and when to communicate with them — most partners tell merchants in advance that the migration is handled by the platform, so nobody acts on Teya's notice by looking for a new provider. If you would like support or guidance with that communication, ask your Teya partner contact.

Which of my merchants are on the legacy platform?

Every merchant that pays through your legacy integration is on it — your own merchant records are the list. Use them to plan and track the migration store by store. If you need help identifying stores or reconciling them with Teya's records, ask your Teya partner contact.

A merchant uses my platform and their own direct integration. Who migrates what?

Each integration is migrated by whoever built it: you migrate your platform's integration for that merchant's store, the merchant's own developer follows the Businesses guides for theirs. Credentials are per store, so both can proceed independently.

Do I need to be certified, or identify my plugin?

No certification. If your merchants integrate through a plugin, Teya assigns a plugin_type for you to send with each credential exchange or registration; it identifies your integration for support and debugging.

How does the stored-card migration work across many merchants?

The four phases run per merchant, and the import in Phase 3 is per merchant. Agree phase dates with your Teya partner contact in batches, and confirm a merchant for import only once Phase 1 is complete for every store and code path. See the stored cards guide.

What if some of my merchants haven't moved by the retirement date?

Any merchant still on your legacy integration when the platform is retired will stop being able to take payments through it. Agree a migration plan and completion date with your Teya partner contact; we will contact you before any of your merchants is affected, and work with you to avoid it.

```admonition icon: fas fa-life-ring title: Question not answered here? content: Contact your Teya partner contact. For integration questions, see Support. ```

Next steps

• Migration overview - Find your path and the guide that applies
• Migrate with an AI assistant - Prompts and a downloadable pack for LLM-assisted migrations
• Testing - Test cards and integration checklist
• Support - How to reach Teya