Snippet API reference

This is the full reference for the helper your page uses to talk to the Web SDK. Keep it open alongside the Web SDK guide while you build.

Before you begin

• Load the snippet and add the iframe as shown in the Web SDK guide.

What you'll do

• Look up each method, its parameters, and the options it accepts.

The PayMitto snippet (snippet.min.js) exposes the window.rremit object with the following methods for communicating with the SDK iframe.

init

window.rremit.init(payload, onCreateCallback, onUnloadCallback, options)

Initializes the SDK iframe with the provided configuration payload.

completed

window.rremit.completed(transferId)

Posts the completed transfer ID back to the SDK iframe to render the confirmation screen.

failed

window.rremit.failed(error)

Posts an error back to the SDK iframe so it can display the error to the user.

Expected error structure:

{
  response: {
    data: {
      code: 400,
      message: "Insufficient funds"
    }
  }
}

Session activity and logout

In addition to the transfer lifecycle methods above, the snippet exposes a small set of methods for coordinating session state between your host page and the SDK iframe. These let you keep an active SDK session alive while the user interacts with your surrounding page, end the SDK session when the user signs out of your app, and react when the SDK ends its own session.

activity

window.rremit.activity()

Notifies the SDK of host-side user activity, resetting the SDK's inactivity timer (see idleTimeout in SDKCoreOptions). Call this when the user interacts with your surrounding page so that an actively-engaged user isn't logged out by the SDK's idle timeout. Takes no arguments.

logout

window.rremit.logout()

Tells the SDK to end its current session and log the user out. Use this when the user signs out of your host application so the SDK session is terminated in step with it. Takes no arguments.

on

window.rremit.on(event, callback)

Registers a callback for session lifecycle events emitted by the SDK iframe. Calling on again with the same event replaces the previously registered callback. These events are only delivered after init has run, since init installs the listener that dispatches them.

Events

Example

// React when the SDK ends its session
window.rremit.on("logout", () => {
  // The SDK session has ended — return the user to your app
  window.location.assign("/dashboard");
});

// Keep your host session alive while the user is active in the SDK
window.rremit.on("activity", () => {
  keepHostSessionAlive();
});

options

The optional fourth argument to init. These options configure the snippet's behavior on your page, and are separate from the initialization payload sent to the SDK.

debug

Enables verbose snippet logging, useful when diagnosing integration issues such as out-of-order calls, a missing iframe element, or unexpected message traffic between your page and the SDK. Defaults to false: no output is produced.

window.rremit.init(
  payload,
  onCreateCallback,
  onUnloadCallback,
  { debug: true }
);

What gets logged

When debug is enabled, you'll see two kinds of entries in the browser console:

• snippet:call <method>: emitted whenever a window.rremit.* method is called from your page. Use this to verify that your integration is invoking the snippet in the expected order. For example, snippet:call getIFrame {found: true} confirms the iframe element was located, while {found: false} indicates a missing or incorrectly-named <iframe id="readyremit-iframe"> element.
• snippet:<event>: internal lifecycle traces such as the snippet receiving a postMessage from the SDK iframe, the initial handshake completing, or a previous listener being removed before re-initialization.

The internal lifecycle traces (snippet:<event>) you may encounter include:

• snippet:execute / snippet:define: the snippet script ran and defined window.rremit.
• snippet:already defined in window: the snippet was loaded more than once; the duplicate load is a no-op.
• snippet: prevListener found, removing: a previous init message listener was torn down before re-initializing.
• snippet:message received <type>: a postMessage arrived from the SDK iframe (e.g. readyremit-ready, readyremit-create-transfer).
• snippet:message readyremit-ready ignored: a duplicate ready handshake was received after init had already been sent.

Example: a healthy initialization

A normal startup handshake produces a sequence like this:

snippet:call init {hasPayload: true, hasOnCreate: true, hasOnUnload: true}
snippet:call getIFrame {found: true}
snippet:message received readyremit-ready
snippet:call postMessage {type: "readyremit-initiate"}

Use it to localize a failed integration:

• If you see getIFrame {found: false}, your <iframe id="readyremit-iframe"> element is missing or incorrectly named.
• If the sequence stalls before snippet:message received readyremit-ready, the iframe never finished loading the SDK. Verify the iframe src and that it points at the correct environment.

Privacy and sensitive data

The snippet sanitizes log entries before emitting them. The encrypted resources token, your customer ID, and the full initialization and transfer payloads you pass to the SDK are never written to the log. For those, only structural metadata is recorded (method name, event type, and presence flags such as {hasPayload: true}).

Two identifiers are logged in full, by design, because they are what support needs to trace a transfer end to end:

• completed(transferId) logs the raw transferId.
• failed(error) logs the error's name, message, and response.status. The error response body (response.data) is never logged.

That said, do not ship debug: true to production. The intended use is local development or a temporary capture during a support session. Once you've reproduced an issue, share the captured console output with PayMitto support.

scrollOffset

Tells the snippet how much room to leave at the top of your page whenever the SDK asks it to scroll.

When you need it

Only when iframeResize is enabled. In that mode the iframe is sized to its full content height and your page (not the iframe) is the scroller, so the SDK asks your page to scroll on each in-SDK navigation and when a modal opens.

If your page has a position: fixed header, those scrolls put the top of the SDK underneath it. scrollOffset is the height of that header.

Usage

// Static header
window.rremit.init(payload, onCreate, onUnload, { scrollOffset: 80 });

// Header whose height changes — breakpoints, sticky-collapse, dismissible banners
const header = document.querySelector("#site-header");
window.rremit.init(payload, onCreate, onUnload, {
  scrollOffset: () => header.offsetHeight,
});

Prefer the function form for anything that isn't a fixed pixel height: it is re-read on every scroll, so it stays correct as the header changes. A number is read once, at init.

Behavior

• Defaults to 0. Omitting the option leaves scrolling exactly as it was before the option existed.
• Applies to both scroll positions the SDK requests: scroll-to-top after navigation, and centering when a modal opens.
• Values that are not a finite positive number (a resolver that throws, NaN, a negative, a numeric string, a non-number return) fall back to 0. The scroll still happens; a bad offset never blocks navigation.

📘

CSS-only alternative

If you cannot change your init call, declare the inset in CSS on the iframe instead:

CSS

#readyremit-iframe {
  scroll-margin-top: 80px;
}

The snippet leaves this in place when no scrollOffset is passed. Two limits: the value is static, so a media query is the only way to vary it by breakpoint, and it does not affect modal centering.

scroll-margin-top is safe to set this way because the snippet never writes it. Note that the same is not true of border and padding: under iframeResize the snippet overwrites both on the iframe. See iframeResize and iframe styling.

Next steps

• Web SDK authentication: set up the token your init payload carries.
• Transfer status updates: follow a transfer after it is submitted.