Before you begin

This section is the whole setup, in order. It says what Stratsol provides, what you provide, what you do not need, and what changes when you go to production. The integration guides then show how to build, and they link back here rather than repeating it.

The order things happen in

1. Stratsol sets up your sandbox merchant   and gives you its Merchant ID and credentials
2. You register and get access              your developers register; an administrator attaches them
3. You set up the sandbox                   what to ask Stratsol for, for your integration
4. You prepare your test payment methods    Google Pay and Apple Pay each have their own needs
5. You build and test                       following the guide for your integration
6. You prepare for production               what changes, and who registers what

The sandbox is Wasp's test environment; Stratsol also calls it Stage.

What Stratsol provides

Item	What it is for
A sandbox merchant	The merchant your integration acts for. Stratsol creates it; you cannot.
Its Merchant ID and Aggregator ID	They identify your merchant on every call your backend makes.
An API key and a key phrase	Your backend's credentials. Both are secrets and stay on your server.
The sandbox base URL	Where your backend calls Wasp: https://stage.api.strat-sol.biz. It is the same for every sandbox merchant; production has its own, which Stratsol gives you with your production credentials.
The payment methods you need, switched on	Card, Google Pay or Apple Pay. A method that is not switched on is refused.
The configuration you ask for	Your outcome callback URL, and, where your integration needs them, your checkout domains or your Hosted Checkout return profiles.
Access to the protected documentation	Once an administrator has attached you to your merchant. See Register and get access.
Every wallet key and identity	Wasp is the Google Pay gateway and the Apple Pay platform, and it holds the keys that open wallet payment data. You never receive them and never need them.

The full list, and where each item goes, is in What Stratsol provides and what you provide.

What you provide

Item	When you need it
Which integration you are building, and which payment methods	Always. See Choose your integration.
The email address each of your developers registers with	So Stratsol can recognise their access requests.
Your own application, served over HTTPS	Whenever a customer pays in a browser: Embedded Checkout, client-owned collection, and the return page for Hosted Checkout. Google Pay and Apple Pay run only on a secure page. The Direct Payment API, with no browser, needs only your backend.
An outcome callback URL: a public HTTPS address on your server — while you develop, a tunnel to your machine; see Receiving notifications on your own machine	Before you test anything that can finish later (a 202). Embedded Checkout and client-owned collection need one; Hosted Checkout does not. The Direct Payment API needs one only for Digital entry, such as a PreAuth and its Advice; the Manual card payments in its examples are never answered 202.
Your checkout domains	Embedded Checkout, and Apple Pay on your own page. Not client-owned Card or Google Pay.
Your Google Merchant ID, issued to you by Google	Google Pay on Embedded Checkout, before you go live; Stratsol records it on your merchant. Not needed to test, and not for Hosted Checkout. See who registers what with Google and Apple.
Your website address and return destinations	Hosted Checkout only.

What your business provides

Stratsol sets up your merchant from these. Your developers do not need them, but someone in your business does, and setup waits for them.

Item	What it is for
Your business name	What your merchant is called. It is fixed once your merchant is created, so check the spelling. Customers see it wherever you have not set a trading name.
Your business address, time zone and ABN	Who and where the merchant is. Wasp uses the name and address to describe you on your payments.
Your website address	Your main site.
A business contact and a technical contact	Who Stratsol talks to about the commercial relationship, and about the integration.
A cardholder support phone number	The number your customers call about a payment. It reaches the public, so give a support line, not a developer's mobile.
Your settlement bank account	The account your payments are settled to: BSB, account number and account name.
A report email address	Where your merchant reports go, and whether you want them.
Your trading name, logo and colours	Optional, for Hosted Checkout. You can also set them yourself later; see Hosted Checkout branding.

Stratsol and the acquirer supply the rest: the schemes you can accept, your acquirer numbers, and the commercial terms you agreed.

If you are an aggregator

An aggregator is the organisation a group of merchants sits under. Stratsol sets up the aggregator first, from:

Item	What it is for
Your aggregator name	Fixed once created.
Your aggregator contacts	A commercial and a technical contact, and your website.
A report email address	Where your reports go.
Your own reference for each merchant, if you have one	Stored with each merchant for your records. Wasp does not use it, and it is not the Merchant ID.
A default outcome callback URL, if you receive outcomes for your merchants	Used for any merchant that has no callback URL of its own.
Default return destinations, if your merchants share them	Used for Hosted Checkout by any merchant without its own of the same name.

Settings at the aggregator apply to every merchant beneath it. Each merchant still provides its own items above.

What you do not need

• Wasp's keys or certificates, for any payment method.
• A Google Merchant ID, or any registration with Google, to test in the sandbox.
• Apple certificates or an Apple merchant identifier. To test Apple Pay you do need an Apple Sandbox Tester account, which a member of an Apple Developer Program team creates in App Store Connect; see Testing Apple Pay.
• A checkout domain for client-owned Card or Google Pay.
• Return profiles, unless you use Hosted Checkout.

What to do next

1. Ask Stratsol for your sandbox merchant. Email support@strat-sol.net with the integration and payment methods you chose, your developers' email addresses, and the business details above. Your outcome callback URL and checkout domains can follow once you have them, but Embedded Checkout does not start without its checkout domain, and nothing that finishes later (a 202) can be tested without the callback URL. Stratsol creates your merchant, tells you its Merchant ID, and gives you your sandbox API key and key phrase securely. Never send or ask for them by email.
2. Register and get access.
3. Set up the sandbox for your integration.
4. Prepare your test payment methods: Google Pay · Apple Pay.
5. Build it: follow the guided journey for your integration.
6. Prepare for production, including who registers what with Google and Apple.