Security overview
Two ideas cover almost everything in this section. If you take nothing else from it, take these.
1. The browser is untrusted
Anything in a browser can be read and changed by the person using it. So the browser is allowed to collect a payment credential, and nothing else.
BROWSER MAY HOLD BROWSER MUST NEVER HOLD
merchantId API key
waspBaseUrl key phrase / signing secret
browser-safe checkout config private keys
the public encryption key acquirer credentials
an opaque collected instrument decrypted PAN/DPAN, CVV/CCV, cryptograms
PAN and DPAN are card numbers, CVV/CCV is the card security code, and a cryptogram is a one-time code a card or wallet makes for a single payment. The glossary explains each.
And because a value the browser holds is a value a customer can change, the
browser never decides the amount, the currency, the reference, the merchant, or
where the customer is sent afterwards. Your backend decides all of those.
2. Only a server-side answer is proof
A payment succeeded when Wasp says so, server-side. Nothing the browser touches counts:
| Signal | Proof? |
|---|---|
An HTTP 200 from the Payment API | No, not on its own. It means the request was processed. Read payment.approved from it — that is proof. |
| A successful wallet collection in the browser | No. That is a credential, not an approval. |
A customer arriving on your return page with outcome=success | No. It is a URL, and a customer can edit it. |
| An outcome notification whose signature you have not verified | No. Anyone can POST to your endpoint. |
| An outcome notification whose signature you have verified | Yes. Only Wasp holds your key phrase. Read payment.approved from the body. |
payment.approved from a server-side lookup by reference | Yes. |
The dividing line is not "which channel" but "did Wasp authenticate it". A 200
to a request you signed, a notification signed with your key phrase, and a lookup
you authenticated are all Wasp speaking to your server. A redirect, a URL
parameter and an unverified POST are not.
See Outcome notifications for verification, and Status lookup by reference for asking directly.
What this section covers
| Page | What it answers |
|---|---|
| Browser/backend boundary | Exactly what may cross, and in which direction. |
| Credential management | How to store, scope and rotate the two secrets. |
| Secrets and redaction | What may be displayed, and what must never be logged. |
| Visibility model | Who can see what in the portal. |
What the portal itself shows
What you can read in this portal follows from three separate facts, and none of them implies another:
| Fact | What it establishes | What it opens |
|---|---|---|
| Registration | Who you are | The guidance for choosing and preparing an integration, your own portal status, and how to ask for access |
| Merchant attachment | Which merchant you work for | Nothing extra on its own. It is the relationship, not a grant: the portal shows you your merchant's details, such as its Merchant ID |
| Access, granted by an administrator | What you may read | Exactly what each access names: the implementation guides and Merchant API reference, the Wasp API reference, or the page for administering users |
Public pages — like this one — need none of them. The Visibility model sets out what each kind of reader can see.
The portal is documentation. It shows no transactions and no payment data. It never exposes raw wallet tokens, decrypted card numbers (PAN), card security codes (CVV/CCV), cryptograms, private keys, acquirer credentials, or another merchant's data. It never shows your API key or key phrase either: Stratsol issues those to you securely.
A key phrase is shown to you only once, when it is issued. If one is lost, it must be rotated: ask Stratsol, and your API key and key phrase are replaced together (see Credential management).
Your side of the responsibility
Wasp minimises what you have to handle; it does not remove your obligations. You still:
- keep the API key and key phrase server-side, and rotate them if exposed;
- keep payment credentials out of your logs, error reports and crash dumps;
- decide fulfilment from an authoritative result, not a browser signal;
- keep sandbox and production credentials strictly separate.
See What Stratsol provides and what you provide for the shared responsibility model.