Skip to content
Status

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.

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.

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"
}
}
}
}
  • "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.
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

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).

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.

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.

Was this page helpful?