Pengaturan
Step-up security
Which money-impact actions make someone re-prove who they are, above what amount, and where every completed verification is recorded.
Terakhir diperbarui
Who this is for: Owner, Manager — requires
core.stepup.manage. Where: Settings → Step-Up Security
Some actions give money away or take it back: a refund, a folio adjustment, a voided check, a comped extra. Holding the permission is not quite enough for those — Nerve asks the person to prove, right then, that they are still the person who signed in.
This screen is where you decide which actions ask, and above what amount. It is also the log of every time somebody was asked and answered.
What a step-up looks like to the person doing it#
They do not come to this screen. They press the button they were going to press anyway, and a dialog appears: Verify it's you. They enter a code, it is checked, and the original action goes through.
| Channel | Where the code comes from |
|---|---|
| Email code | Sent to the account's own address; re-sendable after 30 seconds |
| Authenticator app | Their enrolled authenticator |
The dialog never shows the guest, the folio or the reservation — only what kind of action is being confirmed and for how much. A challenge is bound to one account, one action and one specific resource and amount, so it cannot be verified for a small refund and spent on a large one.
Cancelling the dialog cancels the action. Nothing is half-done.
Require step-up for an action#
- Open Settings → Step-Up Security.
- Find the action under Protected actions.
- Turn its switch on or off.
The change saves immediately and applies to everybody in the organisation.
Set an amount threshold#
- With the action's switch on, type an amount in the Above box.
- Press Enter, or click outside the box.
Below that amount the action proceeds without a challenge; at or above it, the challenge appears. Leave the amount at zero to challenge every occurrence regardless of size.
A threshold is the setting most houses actually want: a five-unit goodwill adjustment at the desk is not the risk, and a challenge on every one of them trains people to click through challenges.
The protected actions#
| Action | Where it happens |
|---|---|
| Folio refund | Payments |
| Folio adjustment | Folios |
| POS discount | The terminal |
| POS void | The terminal |
| Ancillary waive | Ancillary catalog |
| Reveal booking card | The card on a booking's payment record |
Penting
Every one of these is protected by default. The policy here only ever relaxes what the product already requires — an action arrives switched on, and you decide whether to lower it. Nothing has to be remembered into place, which means a new protected action cannot ship silently unprotected.
Read the verification audit#
Under Verification audit, one row per completed step-up: when, which action, the amount, the channel used, and the outcome.
| Outcome | Meaning |
|---|---|
| verified | The person proved who they were |
| applied | The verification was then spent on the action it was issued for |
A long run of verified that never became applied is worth a look: somebody is passing challenges and then abandoning the action.
This is not the same as the partner-portal step-up#
Two different things share the name.
| Step-up security (this page) | Realm step-up | |
|---|---|---|
| Triggered by | A protected money action | Crossing into the partner portal |
| Asks for | A one-time code | Your password again |
| Configured | Here, per action and amount | Not configurable |
Realms covers the second one.
What's next#
- The audit log — the wider trail these verifications sit inside
- Roles and custom permission bundles — the permission half of the same question
- Payments — the screen where most people first meet a challenge