Migration FAQ
The questions the migration guides don't answer step by step: what happens if you wait, what changes for your customers and your back office, and what is different on the new platform. For the technical migration itself, start at the overview.
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?
If your integration is still on the legacy platform when it is retired, your website will no longer be able to take card payments through it. If you sell through a partner platform or use a Teya plugin, the migration preparation is managed for you — but watch for further instructions from your provider or from Teya, because you may need to reconnect your store or sign in again when the switch happens.
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 a B-Gateway username and password, each store gets OAuth API credentials (a Client ID and Client Secret). You create them yourself in the Business Portal under the store's Integrations settings. 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.
I no longer have a developer. What are my options?
Three, in increasing order of effort: switch to a Teya plugin if your shop runs on WooCommerce or Shopify; use Payment Links from the Business Portal or Teya app if you mostly invoice customers; or have any web developer or agency follow the Hosted Checkout guide — it is written so a developer who has never seen SecurePay can do it.
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.
My site is plain HTML with no backend. Can I still migrate?
Yes, but you need one small server-side component: the new platform uses credentials that must never reach the browser, so a session is created from your server before the customer is redirected. A single endpoint — a PHP file on your host or a serverless function — is enough. See Step 1 of the Hosted Checkout guide. If that is more than you want, Payment Links or a plugin need no backend at all.
I use a Teya or Borgun plugin for WooCommerce or Shopify.
Install the current Teya plugin for your platform and connect it to your Teya account — it already uses the new platform. Watch for instructions from Teya, as you may need to sign in again when your store switches over. See Connect with e-commerce platforms and the Help Centre article Set up and connect your plugin to Teya.
A partner platform or agency built my integration. Who does the work?
Your provider does. Partner platforms migrate their integration once for all their merchants; the preparation is managed for you, but watch for their instructions — you may be asked to reconnect your store or approve a connection to your Teya account when the switch happens. Agencies that built a custom integration for you follow the same guides as your own developer would.
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.
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