Merchant View

Merchant View embeds a searchable view of payment activity — transactions, accounts, contracts and batches — directly into your platform. It is delivered as an iFrame via shuttle.js, so card data and PCI scope stay inside Shuttle.

Two modes

Merchant View runs in two modes, selected by mode on the deep link. They are separate on purpose and most platforms expose only the first.

Operations (mode: enquiry) is the day-to-day side: finding a payer, taking or refunding a payment, and managing their agreements and saved payment methods. This is what you would put in front of merchant staff.

Admin (mode: setup) is the administrative side: settings a merchant administers for themselves rather than work on a customer's record. It is a container and we expect it to gain more over time; today it holds the wording customers read — the labels, prompts, messages and emails the checkout and its receipts use. Wording is set once for everybody, so a change reaches every customer of that brand immediately, which makes it an administrator's job rather than something to hand an agent between calls. Whether a merchant sees this mode at all is your decision.

What it shows

• Transactions — search, view detail, capture, void and refund
• Accounts — the payers held against the merchant instance, their payment methods and their history
• Contracts — recurring and scheduled agreements, including arrears and future charges
• Activity dashboard — volume and status charts for the instance

The view can be opened whole, or scoped straight to a single account, contract, transaction or payment method — which makes it equally suitable as a merchant-facing activity screen or as a panel inside your own support tooling.

What the merchant sees

Every screen is documented, one page per screen, with the controls and what each one does:

• Merchant View - Operations — account, contract, transaction and payment method screens, the searches that reach them, and the sections they share
• Merchant View - Admin — today, the localisation editor

Read those when you need to know what a merchant will be looking at, or when you are writing your own help material. What each control is allowed to do, what it refuses and why, and what it changes, is in Business Rules — the same rules the API follows, so a control here and the equivalent API call behave identically unless the page says otherwise.

Embedding

Create a deep link of type dashboard via the Deep Link Creation API, then pass the returned ID to data-shuttle-embed on your page. Step by step, with the browser events to handle: Merchant View Integration Guide. The context object on that deep link selects what the merchant lands on (mode, action, id / alt_key) and how much chrome is shown (menu, menu_logo, return_url).

module is accepted as a synonym for mode.

Configuring

Merchant View is not all-or-nothing. Every action it exposes — refunds, captures, taking a payment, editing a payer, amending a contract — can be switched off, either as a default for your whole application or per deep link. An option you never set is enabled, so enumerate what you want to remove.

Turning an option off removes the control entirely rather than disabling it, and it narrows what the console offers: it never grants anything the signed-in user could not already do.

See Merchant View Options for the full list, and which screen each one affects.