Migration from version 1.0 to 1.2

Start here if you already integrated Revup Unified SDK 1.0. SDK 1.2 keeps the same script URLs, RevupConfig constructor, and onRevupMessage events — the main changes are checkout layout, APM zone configuration, and styling.

What changed

• Replace flat apms.enabled with apms.primary, apms.secondary, and apms.other arrays of ApmEntry objects.
• Move per-button styles from apms.buttonTypes to each entry's type field; move top-level apms.capabilityDetection to per-entry capabilityDetection: true.
• Move styling from deprecated form.styles / form.buttonStyles to the top-level appearance object (see Appearance API).
• Language codes now use BCP 47 format (e.g. 'en-US' instead of 'en_US').
• form.selfHostedDomain and apms.selfHostedDomain have been removed in patch 1.2.1

What stayed the same

• Script load, container setup, RevupConfig (apiKey, merchantDomain, orderId), and event handling.
• getApmsAvailable()

Next steps

1. Checkout Layout — understand primary / secondary / other zones and the card accordion.
2. Initialization — update mount() options (apms zones, form, appearance).
3. Appearance API — replace form.styles / form.buttonStyles with appearance.variables and rules.

Last changes

Both approaches described in this guide remain fully supported — you do not need to migrate existing integrations. Use this section to understand what changed and, if you want it, how to move from one to the other.

Before (legacy new Revup() + init())

Any configuration change — a new order, a language switch, an appearance tweak, a different set of APMs — required tearing the SDK down and building it again:

revupMessageCleanup();
revup.destroy();
revup = new Revup(newConfig);
await revup.init(newOptions);

This still works today and is not deprecated. The one exception that was always lighter: calling init() again on the same instance with a different orderId re-fetches the order config and re-initializes APMs without a full destroy() + new Revup() cycle.

Now (Revup.mount() + RevupSession.set())

New integrations use Revup.mount(), which returns a RevupSession. Instead of tearing the SDK down, you call session.set(patch) with just the fields that changed, and the SDK figures out internally what needs to be rebuilt:

const revupSession = await window.Revup.mount({
  merchantDomain: window.location.origin,
  apiKey: apiKey,
  containerId: 'revup-container',
  orderId: orderId,
});

// Later — update in place, no destroy/recreate call needed:
await revupSession.set({ orderId: newOrderId });
await revupSession.set({ appearance: { theme: 'dark' } });
await revupSession.set({ apiKey: newApiKey }); // still works — SDK rebuilds itself internally

session.set() inspects which fields changed and picks the cheapest path automatically:

Field	Path	What happens
merchantDomain	Cold (rebuild)	Same as before: full SDK rebuild, but handled internally by set() — you don't call destroy()/new Revup() yourself.
apiKey	Cold (rebuild)	Same as above.
containerId	Cold (rebuild)	Same as above.
orderId	Hot	Re-fetches order config, re-initializes APMs, reuses the form iframe (no reload).
appearance	Hot	Applies CSS variables live, no rebuild.
form	Hot	Re-renders only what changed; the accordion collapsed state toggles without a rebuild.
apms	Hot	Diffs old vs new APM set — unaffected buttons keep their DOM/vendor SDK state.
userInfo	Hot	Re-synced without a rebuild.
language	Full re-init (same instance, not a full teardown)	Buttons/labels need consistent re-rendering.

set() returns an UpdateReport: { path: 'hot' | 'cold' | 'noop', changed, committed?, durationMs, coalesced? } — use it to confirm what actually happened.

Which one should I use?

• Existing integration already using new Revup()? No action required. It keeps working exactly as documented in sections 3–7 Integration Guide and Initialization.
• New integration, or migrating an existing one? Use Revup.mount() from the start (see the Quick start section) — you get the same result with less code, and never need to call destroy()/new Revup() manually except when the session itself ends.

Refer to Integration Guide only if you need a full walkthrough of steps 1–4 and 8.