Visibility model
Who can read what in this portal, and what decides it.
Three facts, kept apart
Three different things are often confused. Keeping them apart is the model.
| Fact | What it establishes | What it opens on its own |
|---|---|---|
| Registration | Who you are. Anyone may register; it is self-service. | The guidance every registered developer can read |
| Merchant attachment | Which merchant you work for. An administrator for that merchant approves it. | Nothing. It is a relationship, not a grant |
| Access | What you may read. An administrator grants it deliberately, usually in the same step as attaching you. | Exactly what that access names, and nothing else |
So a registered developer who is not attached to a merchant can learn the platform and plan an integration — concepts, integration choices, prerequisites, how to request access — while still seeing no implementation guides, no API reference and no credentials. An attached developer with no access sees the same. Attachment alone is never "see everything".
What each kind of access opens
| Access | What it opens |
|---|---|
| None — anyone, without signing in | The public pages: what Wasp is, the integration choices, this security guidance, support, the legal notices, and the public Checkout SDK assets |
| Registered — every registered developer | Also: the guidance for choosing and preparing an integration, your own portal status, and the form to request access to a merchant |
| Merchant API reference | The implementation guides, the runnable examples and the Merchant API reference (client.yaml) |
| Wasp API reference | The Wasp API reference (wasp.yaml): the broader Wasp contract, including the administration operations Stratsol runs |
| User administration | The page for administering developers — approving access requests, attaching developers and choosing their access — its guide, and the full Wasp style guide |
| Admin API | The guides Stratsol's operators use to onboard merchants and aggregators |
These are not levels. Each access opens only what it names, and holding one never implies another: Wasp API reference access does not open the implementation guides, user administration does not open either reference, and Admin API access opens neither the references nor user administration. The API reference overview describes the two references.
Reading a reference is not permission to call anything. Every call to Wasp is checked against the credentials it carries, whatever you can read here.
How it is enforced
Every page declares the access it needs, and the portal checks it on every request. A page that declares nothing is refused rather than shown. The search only ever matches pages you are allowed to read.
Hiding a navigation link is not access control, and never counts as one. The menu leaves out what you cannot open so that it stays useful; the check on the page itself is what protects it.
What a reader has looked at never influences what they are granted, and no answer given at registration shapes what anyone can read.
What the portal shows about your merchant
Once you are attached, the portal can show your merchant's non-secret details — its name, Merchant ID, Aggregator ID, its checkout domains and the names of its return profiles — so that the guides can fill them in for you. It shows only your own merchant's. It does not show which payment methods are switched on or whether an outcome callback URL is set; ask Stratsol if you are not sure.
Your API key and key phrase are never shown in the portal. Stratsol issues them to you securely.
What the portal never shows
The portal never exposes raw payment instruments, wallet tokens, decrypted card numbers (PAN or DPAN), card security codes (CVV/CCV), cryptograms, private keys, acquirer credentials, private routing or risk rules, or another merchant's data. Stratsol's own internal operations are not published in either API reference.
API key identifiers and names may be shown. Signing secrets are shown only at creation time, and a lost signing secret must be rotated.