Organization Settings
Organization Settings is where your school's own configuration lives — its name and branding, the signatures printed on certificates, reusable class schedules, your payment processor connection, and the tokens external systems use to read your public course data.
Organization appears in the sidebar only for Super Admins, under Settings. An Admin sees the Administrator section but no Settings group beneath it.
This is enforced, not just hidden: typing the URL directly sends a non-Super-Admin back to the Dashboard. The page holds your payment credentials, which is why it's locked down more tightly than anywhere else in the application.
Find it at Admin > Settings > Organization. It has five tabs, and the tab you're on is kept in the address bar, so you can bookmark or share a link straight to one.
General
Organization Profile
| Field | Notes |
|---|---|
| Organization Name | Used on certificates, emails and the browser tab title |
| Website | Where the sidebar's "Back to website" link goes. Must include https://. |
| Contact Phone | Shown to students |
| Contact Email | Shown to students |
Logo
Upload a logo and crop it before saving — to a square, to a rectangle, or not at all. The logo appears on the site, on certificates and in emails.
Terms & Conditions
Below the profile form. This is the text students agree to when registering for a class, shown on the public register page.
Certificate Signatures
The signatures printed on student certificates.
| Field | Notes |
|---|---|
| Name | The signatory's name |
| Title | Their title, printed beneath the name |
| Signature image | Uploaded per signature |
Signatures can be deactivated and reactivated rather than deleted, so a certificate issued under a previous signatory keeps its record. The Active / Deactivated tabs filter the list.
A signature is chosen per certificate template, on a course's Certificates tab.
Schedule Templates
Reusable schedule presets, so a class that always runs the same shape doesn't have to be built by hand each time.
| Field | Notes |
|---|---|
| Template name | How you'll recognise it when scheduling |
| Schedule | The day-by-day pattern |
Create one with Create Template, then pick it when scheduling a class. Templates can be edited and deleted.
Payment Settings
Your Stripe connection and card surcharging.
Stripe Connection
| Field | Notes |
|---|---|
| Environment | Live or Test — "Which set of Stripe keys the saved credentials belong to." |
| Publishable Key | "Used in the browser to collect card details." Must start with pk_. |
| Secret Key | "Used server side to create charges. Never share it." |
Once saved, the secret key is write-only. You won't see it again, and it's only sent to the server when you deliberately replace it — the field shows "Saving replaces the stored key. It is never shown again."
Keep your own copy in your password manager. If it's lost, generate a new one in Stripe and paste that in.
The form checks that the key matches the environment. If it doesn't, you'll see either:
- "This is a test key, but the environment is set to Live."
- "This is a live key, but the environment is set to Test."
- "That publishable key does not belong to the selected environment."
Fix the mismatch before saving — a live environment with test keys takes no real money.
Surcharge Configuration
| Field | Notes |
|---|---|
| Enable surcharging | A switch. "Turn off to stop adding a surcharge to card payments." |
| Surcharge Percentage | Required when enabled. Between 0.1% and 3%, to two decimal places. |
Once on, AnchorPoint handles the rest:
- The fee is disclosed before a payment is submitted, everywhere a card is taken — public registration, the student's payment drawer, and the admin Create Payment drawer.
- It always shows as its own line beside the amount, never folded into the balance.
- Debit and prepaid cards are never surcharged. When a newly entered card's type isn't known yet, the rule is explained in plain words rather than a figure.
- Admins can waive it on any payment they record, with a reason.
- A cash or check refund returns the principal only — the surcharge comes back only through a card refund.
See Payments for how this looks day to day.
API Tokens
Tokens let an external system — most often your marketing site — read your public course and class data through the AnchorPoint API. They're read-only and reach nothing private.
There's a link from this tab through to the developer documentation, which is what you hand to whoever is building the integration.
What Each Column Shows
| Column | What It Shows |
|---|---|
| Name | The consumer this token is for |
| Status | Active, Expired, or Revoked |
| Last Used | In plain words — "3 days ago", or "Never used". Hover for the exact timestamp. |
| Expires | The expiration date, or never |
| Created | When it was issued |
| Actions | A menu button with additional options |
The status filter opens on the tokens still authenticating, so revoked and expired ones are out of the way until you look for them.
Creating a Token
| Field | Required? | Notes |
|---|---|---|
| Name | Yes | "The consumer this token is for. A name cannot be reused once its token is deleted." Maximum 255 characters. |
| Never expires | No | A switch. "Recommended only for tokens you actively monitor." |
| Expiration Date | Unless never expires | "The token stops authenticating at the end of this day." |
An expiration date applies at the end of that day in your own timezone, so a token set to expire on a date is good for the whole of it.
When the token is created, its secret appears in a modal you can only dismiss with the confirm button. Copy it then — it is never recoverable afterwards. If it's lost, rotate the token to issue a new one.
Managing a Token
The three actions look similar and do very different things. The dialogs spell out the difference.
| Action | Reversible? | What Happens |
|---|---|---|
| Revoke | Yes | Stops authenticating on its very next request. Reactivate later and the same secret works again. |
| Rotate Secret | No | A new secret is issued and the current one stops working immediately, so anything still using it starts failing until you paste the new one in. Name, expiration and status are unchanged. |
| Delete | No | Stops authenticating immediately and disappears from the list. The name is then permanently reserved and can never be used by a new token. |
Revoking gets you the same immediate result and can be undone. Delete only when you're certain, and remember it burns the name for good.
Rotating Without Downtime
Rotating breaks the old secret instantly. Coordinate it: have the developer ready to paste the new secret in, rotate, then confirm the integration is working. See Handling a rotated token without downtime in the developer guide.
When Things Are Disabled
| What's Disabled | Why |
|---|---|
| The whole Organization Settings page | You're not a Super Admin. Typing the URL redirects you to the Dashboard. |
| Surcharge Percentage | Enable surcharging is switched off |
| Expiration Date on a token | Never expires is switched on |
| Reactivate on a token | The token has expired. The menu item says "This token has expired. Extend its expiration date before reactivating it." — extend the date first. |
| The secret key field shows nothing | By design. It's write-only once saved. |
| Card payments across the application | The Stripe connection isn't configured, or the keys don't match the environment. |
Key Relationships
- Certificates: signatures created here are selected on a course's Certificates tab and printed on issued certificates.
- Classes: schedule templates created here appear when scheduling a class.
- Payments: the Stripe connection and surcharge rate set here govern every card payment in the application.
- Public registration: the Terms & Conditions and the logo set here are what students see.
- Developers: API tokens authenticate the public course and class endpoints documented in the developer guide.
Tips & Notes
- Test the Stripe connection in Test mode first. Switching to Live with the wrong keys means no money is actually taken, and you may not notice for a while.
- Store the secret key somewhere before you save it. The field is write-only afterwards, and there's no way to read it back out of AnchorPoint.
- Give tokens the name of the thing using them, not the person who asked for them. "Marketing site" tells the next Super Admin what breaks if they revoke it; a person's name doesn't.
- Set an expiry on every token you can. A token with no expiry and no recent use is the one that gets forgotten. The Last Used column is there to help you spot them.
- Deactivate signatures rather than replacing them. A certificate issued under a previous signatory should keep its record.