Skip to main content

Get ready

This step is part of every integration path. Choose your integration to see what comes before and after it.

Register and get access

Create an account​

Registration is open and self-service. Go to /portal/register, create an account, and verify your email address. You do not need an invitation and you do not need to speak to anyone first.

That gives you an identity. It does not give you access to anything protected, and that is deliberate.

Registering means the terms of use apply to you, and the privacy notice describes what is collected — your email address and what to call you, and nothing else. Both are short, and worth the two minutes before you create an account rather than after.

The three facts, and why they are separate​

Getting from "I have an account" to "I can build" is three separate steps. None of them implies another.

1. REGISTRATION      proves WHO YOU ARE
   self-service, right now
        ↓
2. MERCHANT          establishes WHICH ORGANISATION you work with
   ATTACHMENT        requested in the portal, approved by an administrator
        ↓            for that merchant
3. SCOPES            establish WHAT YOU MAY DO
   chosen by the approver, in the same action

Being attached to a merchant does not mean "show me everything that merchant could possibly see". Each protected thing is named by a scope, and a scope is granted on purpose — but granting it is not a second request you have to chase. The administrator who approves your access chooses the scope at the same moment, so one approval attaches you and gives you what you were approved for.

What registration alone gets you​

Registering is not a waiting room. Before anyone approves anything, you can read enough to choose your integration and prepare for it:

That is deliberate. You should be able to decide how you are going to integrate, and know exactly what you need, before you ask anyone for anything. What registration does not give you is the exact API reference, the runnable implementation material, credentials, or the ability to take a payment.

What you get at each step​

AnonymousRegisteredRegistered + attached + scoped
Public documentationYesYesYes
Your portal status, and how to request access—YesYes
Choosing an integration, and what each one involvesPartlyYesYes
Prerequisites, outcomes, testing and go-live concepts—YesYes
Merchant API reference (client.yaml)——With Merchant API reference access
Runnable implementation guides and backend tracks——With Merchant API reference access
Wasp API reference (wasp.yaml)——With Wasp API reference access
Sandbox merchant and credentials——Arranged with Stratsol

A registered developer with no merchant can learn the platform and plan their integration. They get no credentials, no exact API reference, no runnable implementation material, and no ability to take a payment.

Requesting access​

This is the order things happen in for a new client. You cannot ask for access to a merchant until Stratsol has created it and told you its ID.

  1. Stratsol sets up your sandbox merchant. Tell Stratsol which integration and payment methods you are building, and the email address each of your developers will register with. Stratsol creates your sandbox merchant and gives you its Merchant ID, with your sandbox credentials. See What Stratsol provides and what you provide.
  2. Each developer registers at /portal/register, and verifies their email.
  3. Each developer signs in and requests access to the merchant, using the Merchant ID from step 1. Sending the request may take you briefly through the sign-in page, so Wasp can confirm it is you. Usually you will not need to type anything; if your sign-in has lapsed, sign in again and the request is sent.
  4. An administrator for that merchant approves it. For a new merchant, that is Stratsol. Approving attaches the developer to the merchant and grants the access chosen, normally Merchant API reference access. That opens the Merchant API reference and the runnable implementation guides.
  5. The developer can now follow the protected guides for your integration.

Steps 1 and 4 involve another person. That is by design, not a gap: they hand out the ability to move money on someone's behalf. They are an approval, not a tutorial — nobody needs to explain how Wasp works to you before you can ask.

You can register and read the preparation material at any point, before or while this happens. See Before you begin for the whole sequence.

What is not self-service​

Creating your own API key, rotating a signing secret, adding a Checkout Web Domain, switching a payment method on, and issuing sandbox credentials are all arranged with Stratsol. The portal has no screen for them.

Security boundaries​

At no access level does the portal expose:

  • raw wallet tokens;
  • decrypted card numbers (PAN);
  • card security codes (CVV/CCV);
  • cryptograms;
  • private keys or Apple Pay private keys and certificates;
  • acquirer credentials;
  • internal routing or risk rules;
  • another merchant's data.

API key identifiers and names may be shown. Signing secrets are shown only at creation time; a lost signing secret must be rotated. Raw payment instruments and private keys are not visible in the portal.

Last updated on