Merchant Activity Options

Every action Merchant Activity exposes can be switched off — refunds, captures, taking a payment, editing a payer, amending a recurring schedule. 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 Merchant View. The options you set there are the defaults for every Merchant Activity 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, role or screen — for example, a read-only view for support staff and a full view for finance:

{
  "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`
`account_edit`	Creating and editing payers	The "New account" button and the edit action on a payer's details are removed. Payer records become read-only.
`comments`	Comment threads	The comments panel is removed from accounts, transactions, contracts, payment methods and batches.
`manual_capture`	Settling an authorisation	The "Capture" and "Void" buttons are removed from an authorised transaction.
`moto_payment`	Taking a payment from a payer's screen	The "New payment" button is removed from the payer's screen. It does not cover taking a payment against a schedule in arrears — that is governed by `recurring_edit`.
`moto_tokenise`	Storing a payment method without charging it	The "Add payment" button is removed from the payer's screen.
`payment_method_edit`	Changing the payment method on a recurring schedule	The "Change payment method" action is removed.
`recurring`	Recurring schedules as a whole	The Recurring menu, the recurring sections on payers and payment methods, and the recurring chart on the activity dashboard are all removed. Payments taken through the view are forced to one-off.
`recurring_edit`	Amending an existing schedule, and taking or scheduling a payment against one in arrears	"Suspend", "Resume", "Terminate", "Make payment", "Schedule payment" and "Edit next charge" are removed. The schedule remains viewable.
`recurring_edit_in_place`	Letting staff choose whether an amendment updates the existing schedule or replaces it	The "Update existing schedule" checkbox is disabled, so every amendment terminates the schedule and creates a replacement. The panel explaining what will happen still shows.
`refund`	Refunds	The "Refund" button is removed from a transaction.
`refund_offline`	Recording a refund settled outside Shuttle	Only refunds processed through the gateway are offered.

Taking Payments

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

moto_payment covers the "New payment" button on a payer's screen.
recurring_edit covers "Make payment" and "Schedule payment" against a schedule 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 schedule in arrears. To remove staff-initiated payments entirely, disable both (or disable recurring, which removes the schedule screens altogether).

Permissions Still Apply

These options narrow what the component offers; they do not grant anything. A user still needs the underlying permission on the instance, and the user's own permissions are carried on the deep link. An action appears only when the option is enabled and the user is permitted to perform it.