Merchant View Options

Every action Merchant View exposes can be switched off — refunds, captures, taking a payment, editing an account, amending a contract. Turning an option off removes the control from the UI entirely; it is not greyed out, and the merchant is not told it exists.

Options are set in one of two places.

Set On The Application

In the Developer Portal, open your application, choose the Developer tab and then Configure Merchant View. The options you set there are the defaults for every Merchant View session created by that application.

Test and live applications hold their own values, so you can prove a configuration in sandbox before applying it to production.

Set On The Deep Link

Pass a features object in the context of a dashboard deep link. It overrides the application defaults for that session only, which lets you vary the view by user or screen — for example, hiding refunds from a screen where your staff never need them. It changes what is shown, not what is allowed: to restrict what a user can do, set their role with session.teams (see Permissions Still Apply).

{
  "deep_link": {
    "type": "dashboard",
    "user": { "alt_key": "user-1234", "name": "Sam Taylor" },
    "context": {
      "mode": "enquiry",
      "features": {
        "refund": "FALSE",
        "manual_capture": "FALSE",
        "account_edit": "FALSE"
      }
    }
  }
}

Values

"TRUE" enables the option, "FALSE" disables it. Booleans (true / false) are accepted in context.features.
An option you never set is enabled. Enumerate what you want to remove, not what you want to keep.
The deep link always wins over the application default. An option omitted from features keeps the application default.
Some options depend on another. recurring_edit and recurring_edit_in_place only have an effect while recurring is enabled, recurring_edit_in_place only while recurring_edit is too, and refund_offline only while refund is enabled — disabling a parent disables everything under it, whatever the child is set to.

Options

Option	Controls	Effect when `FALSE`	Screen
`account_edit`	Creating and editing accounts	Create Account and the edit action on an account's details are removed. Account records become read-only.	Create or edit an account
`comments`	Comment threads	The comments panel is removed from accounts, transactions, contracts, payment methods and batches.	Sections on every screen
`manual_capture`	Settling an authorisation	Capture and Void are removed from an authorised transaction.	Capture a transaction
`moto_payment`	Taking a payment from an account's screen	New Payment is removed from the account screen. It does not cover taking a payment against a contract in arrears — that is governed by `recurring_edit`.	Account
`moto_tokenise`	Storing a payment method without charging it	Add Payment Method is removed from the account screen.	Account
`payment_method_edit`	Changing the payment method on a contract	Change Payment Method is removed.	Contract
`recurring`	Contracts as a whole	The Recurring menu, the contract sections on accounts and payment methods, and the recurring chart on the activity dashboard are all removed. Payments taken through the view are forced to one-off.	Contract search
`recurring_edit`	Amending an existing contract, and taking or scheduling a payment against one in arrears	Suspend, Resume, Terminate, Make Payment, Schedule Payment and Edit Next Charge are removed. The contract remains viewable.	Edit a contract
`recurring_edit_in_place`	Letting staff choose whether an amendment updates the existing contract or replaces it	The Update existing contract checkbox is disabled, so every amendment terminates the contract and creates a replacement. The panel explaining what will happen still shows.	Edit a contract
`refund`	Refunds	Refund is removed from a transaction.	Refund a transaction
`refund_offline`	Recording a refund settled outside Shuttle	Only refunds processed through the payment processor are offered.	Refund a transaction

Taking Payments

Two separate options govern staff-initiated payments, and they do not overlap:

moto_payment covers New Payment on an account's screen.
recurring_edit covers Make Payment and Schedule Payment against a contract in arrears.

Disabling moto_payment on its own therefore does not stop staff taking a card-not-present payment — they can still do it from a contract in arrears. To remove staff-initiated payments entirely, disable both (or disable recurring, which removes the contract screens altogether).

Permissions Still Apply

These options narrow what the component offers; they do not grant anything, and they do not take anything away either. They are layout, not security: a hidden control's action is still accepted by the API from a session whose role allows it, including one replaying the component's own calls. An action appears only when the option is enabled and the user's role permits it.

To restrict what a user can do, give their deep link the right role in session.teams: SUPPORT for staff who service customers, SUPPORT_RO for staff who only look. Shuttle checks the role on the server for every action. What each role can do, button by button, is in Merchant View roles; by operation, in Roles and permissions.

What the control itself does

This page says what each option removes. What the control does when it is left in — what it accepts, what it refuses and why, and what it changes — is in Business Rules, which the screens and the API both follow. Where a screen is deliberately stricter than the API, the rule page says so, so you know what a direct API call would still be allowed to do.