# 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 rem

Every action [Merchant View](/platforms/embedded-payments/activity-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](#permissions-still-apply)).

```json
{
  "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](/platforms/user-guides/admin-account-form/) |
| `comments` | Comment threads | The comments panel is removed from accounts, transactions, contracts, payment methods and batches. | [Sections on every screen](/platforms/user-guides/admin-sections-shared/) |
| `manual_capture` | Settling an authorisation | **Capture** and **Void** are removed from an authorised transaction. | [Capture a transaction](/platforms/user-guides/admin-transaction-capture/) |
| `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](/platforms/user-guides/admin-accounts-view/) |
| `moto_tokenise` | Storing a payment method without charging it | **Add Payment Method** is removed from the account screen. | [Account](/platforms/user-guides/admin-accounts-view/) |
| `payment_method_edit` | Changing the payment method on a contract | **Change Payment Method** is removed. | [Contract](/platforms/user-guides/admin-contracts-view/) |
| `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](/platforms/user-guides/admin-contracts-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](/platforms/user-guides/admin-contract-edit/) |
| `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](/platforms/user-guides/admin-contract-edit/) |
| `refund` | Refunds | **Refund** is removed from a transaction. | [Refund a transaction](/platforms/user-guides/admin-transaction-refund/) |
| `refund_offline` | Recording a refund settled outside Shuttle | Only refunds processed through the payment processor are offered. | [Refund a transaction](/platforms/user-guides/admin-transaction-refund/) |

## 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](/platforms/user-guides/operations-roles/); by operation, in [Roles and permissions](/platforms/user-guides/rules-roles/).

## 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](/platforms/user-guides/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.