Accept Shuttle's terms for the instance
Records that the merchant has accepted Shuttle's terms and conditions, as a timestamp and the id of the user who agreed. It is the one-off step Merchant Setup puts in front of a merchant before it will show any other setup screen. The acceptance is a record and nothing more: no server-side check reads it, so the "terms outstanding" flag Merchant Setup acts on is derived on read from this record and from the platform's own acceptance, never stored.
Where you can do this
- Merchant Setup: Accepting the terms (I Agree)
Before you start
- Terms are outstanding: neither the instance's tcs_accepted nor the platform application's accepted_tc is set. A platform that embeds Shuttle's terms in its own (accepted_tc on the application) clears the flag for every one of its instances, and Merchant Setup skips this step without writing anything. Most platforms do this, so the screen is commonly never shown.
- The instance's status is not a precondition: the update is accepted on a suspended or archived instance as readily as on an active one.
Rules
Checked by the API means Shuttle refuses the request however it is sent; a screen name means only that screen refuses it, and a direct API call would be accepted.
| Rule | Checked by | What you see |
|---|---|---|
| The request body must carry an instance object | The API | VALIDATION_ERROR: "API body error: missing instance object" |
| A field left out of the body keeps its stored value: the current instance is read first and the body is filled in from it before anything is written | The API | omitted fields unchanged |
| tcs_accepted is cleared only by an explicit null or empty string, which is the only way to undo an acceptance | The API | acceptance retained |
| tcs_outstanding is derived on read (no tcs_accepted on the instance and no accepted_tc on the platform application); sending it in the body has no effect | The API | ignored |
| A second acceptance is not refused: it overwrites the timestamp and the accepting user. Not enforced server-side; Merchant Setup stops offering the screen once terms are accepted | Merchant Setup screen | screen skipped |
| Nothing server-side reads the acceptance: no payment, checkout, provider connection or capability is gated on it. It is Merchant Setup alone that withholds the rest of setup until it is recorded | Merchant Setup screen | every screen redirects back to the terms screen |
| If something else writes the instance between the read and the write, the save is rejected | The API | INVALID, message key "validations.concurrency.other.user" (absent from the Shuttle message bundle, so the caller sees the key rather than a sentence) |
What happens
- The instance carries the acceptance from then on: tcs_accepted holds the timestamp, tcs_accepted_user the accepting user, and tcs_outstanding reads false. The response is the whole instance as it now stands.
- The merchant goes straight on to their integrations, or to adding their first provider if they have none, and is never shown the terms screen again.
- The platform receives an
INSTANCE.UPDATEwebhook. It is raised on every successful call, including one that re-sends the values already stored. - Nothing else changes: no status transition, no money moved, no email or SMS, and no capability switched on. What changes is that Merchant Setup stops blocking the merchant.
Who can do this
- Roles: Admin only.
- Platform option: application accepted_tc, set per application through the developer portal's gateway setup settings, pre-accepts on the merchant's behalf and suppresses this function entirely for every instance of that application. It is set independently for the live and sandbox applications.
- The terms wording, and the link to the full terms, are Merchant Setup's own translated strings and point at Shuttle's public terms page by default. A platform's branded string overrides only fill in keys the app does not already carry, so they cannot re-word this screen.
Related
Updated 30 minutes ago
Did this page help you?