Overview

Wasp means Workflow Abstraction for Simplified Payments. It is a payments platform you talk to over the internet from your own software, and its job is to keep the complicated parts of taking a payment — card scheme rules, gateways, compliance, day-to-day operations — on its side of a stable, documented boundary rather than yours.

Taking a payment with Wasp has three parts, and it is worth naming them now because every page uses these words:

• Your front end — the page or app your customer sees. It is where they choose how to pay and hand over a card or a wallet. It never holds your Wasp credentials.
• Your backend — your own server. This is where your Wasp credentials live, and the only place that sends a payment to Wasp.
• Wasp — takes the payment from there, and tells your backend what happened.

Two more words you will meet constantly:

• A payment instrument is what your customer handed over, packaged into one consistent shape whatever they used — a typed card, a Google Pay sheet, an Apple Pay sheet. Your code passes it along; it does not need to understand it.
• The cardholder is the person paying. You will also see customer; they mean the same thing here.

Ecosystem roles

• Stratsol — the owning organisation.
• Platform operator — the organisation operating Wasp, usually an acquirer or acquirer reseller.
• Aggregator — an integration partner that owns and manages one or more merchant relationships. Aggregators may onboard merchants, build or host merchant integrations, submit payments on a merchant's behalf, support disputes, and handle settlement or reconciliation obligations.
• Merchant — the entity conducting commerce and processing transactions.
• Cardholder / customer — the person buying from the merchant.
• Operational/admin users — users managing provisioning, configuration, access, and support workflows for the platform operator, aggregator, or merchant.

Every merchant belongs to an aggregator relationship in the Wasp data model. A direct merchant relationship can still be represented by an aggregator with a single merchant, at the platform operator's discretion.

Platform components

Component	Responsibility
Wasp	Payment platform and API suite
Wasp Checkout SDK	Browser-side payment instrument collection
Payment API	Merchant backend payment submission and transaction status
Merchant frontend	Hosts checkout and invokes Wasp Checkout
Merchant backend	Holds credentials, signs requests, submits to Wasp

Typical browser checkout flow

1. The merchant frontend loads Wasp Checkout.
2. Wasp Checkout is initialised with browser-safe configuration: the Wasp base URL, and a payment context the merchant backend obtained from Wasp when it started the checkout.
3. The SDK requests browser-safe wallet configuration.
4. The cardholder chooses a supported payment method and authorises the wallet or card interaction.
5. The SDK returns a normalised payment instrument to the merchant frontend.
6. The merchant frontend sends the instrument to the merchant backend.
7. The merchant backend uses its Wasp credentials and signing material to submit the payment.
8. Wasp processes the payment and returns status/result information.
9. The merchant frontend shows the result and the merchant continues its own fulfilment or support flow.

The important split is deliberate: the browser collects an instrument; the backend initiates the payment.

Credential boundary

The browser may know:

• merchantId
• environment
• browser-safe wallet configuration

The browser must not know:

• API key
• private key phrase / signing secret
• decrypted card numbers (PAN or DPAN)
• the card security code (CVV/CCV)
• private wallet keys
• acquirer credentials

API keys and signing material are environment-specific. The merchant identifier is not a secret, so it may appear in the browser; Wasp Checkout itself is started with the payment context, not the merchant identifier.

Browser-safe does not mean unvalidated. The merchant backend remains authoritative for the order, amount, currency, reference, credentials, request signing, and final payment submission.

Wasp abstracts payment-scheme and compliance detail behind its contracts, but it does not remove the merchant or aggregator's legal, regulatory, scheme, contractual, fulfilment, refund, customer-support, or dispute-response responsibilities.

How Wasp knows a request is really from you

Two separate things, doing two separate jobs.

An API key says which account is calling. It is a long secret string you are given, and your backend sends it with every request in a header — a small named value carried alongside the request itself.

A signature proves the request has not been altered and really came from you. Your backend calculates a short code from the request's contents and the moment it was sent, using a second secret you are given, and sends that code in another header. Wasp recalculates the same code and compares. Change one character of the request in transit and the two no longer match.

That is why the timing matters: the moment the request was sent goes into the calculation and travels with it, so an old captured request cannot simply be replayed later. It also means your server's clock needs to be roughly right.

Two consequences worth reading twice:

• Only your backend ever signs a request. Doing it in browser code would mean shipping the secret to every visitor.
• A lost secret must be replaced, not reused. It is the whole proof.

This page deliberately does not name the headers or restate the calculation. Those are part of the contract you build against rather than the decision you are making now, and they are covered — with the exact names and working code — in HMAC signing and Authentication, which open with Merchant API reference access. The security guidance covers what to keep where, and needs no access at all.

Things that are true of every Wasp API

None of this is unusual if you have called a web API before. It is spelled out because assuming you have is exactly the kind of gap this portal is trying not to leave.

• You send and receive JSON, over ordinary HTTPS requests, using the usual HTTP methods: POST to create something, GET to read it back.

• The HTTP status code tells you which kind of thing happened. Anything starting with 2 means Wasp accepted and answered the request. Anything starting with 4 means there was something wrong with the request — including the case where your credentials were not accepted. Anything starting with 5 means something went wrong at Wasp's end.

  Careful, and this one catches people: a 200 means Wasp answered, not that the payment was approved. The answer is inside the response body, and you have to read it.

• Lists come back a page at a time. Where an operation returns a list — your stored files, for example — you ask for at most so many items, and if there are more the response hands you a token to ask for the next page. Keep going until there is no token left.

• Fixed sets of values are not case-sensitive unless a page says otherwise. Where a field accepts one of a fixed list — a payment's type, say — Sale and sale are both understood.

• Amounts have a defined representation in the contract, and it is not the same in both directions. What you send and what you read back are specified precisely, for a reason to do with keeping money exact. Do not assume you can send back whatever you received without looking.

• Times are always UTC, written in the standard internet format (RFC 3339): 2026-09-20T09:15:00Z. The trailing Z is what says UTC. Send times that way, and expect them back that way.

These apply to every Wasp API, not just payments. The exact header names, the paging parameters and the amount types are contract detail rather than things to decide now; they are set out in API conventions and Pagination, which open with Merchant API reference access.

Supported payment sources

Wasp Checkout collects instruments from three sources, all using the same normalised instrument concept:

• Card entry
• Google Pay
• Apple Pay Web

Which of them a given customer sees depends on your merchant's configuration and their browser and device — not on which of them Wasp supports. Apple Pay carries one prerequisite the others do not: the page must run on an HTTPS domain Stratsol has authorised. What each wallet needs from you, from Google and from Apple, in each checkout, is in the wallets and what they need. See also Payment methods.

What this portal does not cover

Wasp is a platform, and parts of it are not developer-facing. Setting up merchants, issuing credentials and changing merchant configuration, disputes and chargebacks, and settlement reporting are handled with Stratsol rather than through an API you integrate against, so they are not taught here.

If you need one of them, that is a conversation at onboarding, not a gap in these pages. Support is the right place to ask.