Skip to main content

Changelog

Changes to this portal and to Wasp Checkout. The SDK reports its own version at runtime as StratsolCheckout.version.

Within the current series, the current month is listed release by release, and each earlier month is one entry.

Returning after August 2026?

Embedded Checkout has breaking changes. If you wrote against the SDK before 1 September 2026, start with the breaking changes at the top of September 2026 below. create() no longer takes merchantId or transaction, and every mount call now carries the payment lifecycle.

0.6.75 — 16 October 2026​

  • Apple Pay answers a change of card. The Apple Pay sheet now has its payment-method selection answered with the same total whenever the customer picks a card, as Apple requires, in Wasp Checkout and in the client-owned examples.
  • Apple Pay domains, said precisely. Apple's sandbox does not verify domains, so the domain association file is needed to go live, not to test; an HTTPS domain authorised as a checkout domain is still needed from the first test. The go-live checklist now leaves Hosted Checkout out of the domain items, and no longer assumes Apple Pay works only in Safari.
  • Which networks each wallet carries. Google Pay through Wasp: Visa and Mastercard, settled in Australia. Apple Pay through Wasp: Visa, Mastercard and eftpos.
  • Your privacy notice. What your own website must tell customers when you offer a wallet, in every checkout.
  • Privacy notice and terms of use updated. Both name the operator, Stratsol Pty Ltd. The terms state that they cover the portal only, apart from your payments agreement and Apple's and Google's terms. Portal notifications carry identifiers only, and payment data and your payments agreement are described correctly.

0.6.74 — 15 October 2026​

  • Billing address with Google Pay and Apple Pay. Wasp Checkout now asks both wallets for the cardholder's billing postal address and sends it to Wasp with the payment, as billingAddress. It is optional, and a payment without one is processed as normal. To ask for none, pass requestBillingAddress: false to create(), or send "requestBillingAddress": false when you register a Hosted Checkout; an address a wallet returns anyway is still sent.
  • Client-owned Google Pay and Apple Pay show the complete wallet request, including the billing address (strongly recommended), where each wallet's encrypted credential sits, and a signed payment request. The runnable servers forward the billing address with the payment, and the Apple Pay sheet closes as a success only for an approved payment.

0.6.73 — 14 October 2026​

  • Docs opens your documentation, however early you click. Signed in, a click on Docs before the page has finished loading now opens the documentation you can read. It used to open the public pages.
  • Your profile. Change your email address (confirmed with a code sent to the new address), change your password, and close your account yourself.
  • Google Pay and Apple Pay, before you register. A new public page, Google Pay and Apple Pay, sets out what each wallet needs from you, from Google and from Apple, in each checkout, to test and to go live, with links to Google's and Apple's own documentation.
  • Going live with your own Google Pay integration. Client-owned Google Pay now sets out how to get your Google Merchant ID, submit your integration to Google, and pass Google's review of its user experience and branding before your site takes real payments. A Google Merchant ID is needed to go live, not to test.
  • Google Pay on Embedded Checkout uses your own Google Merchant ID in production. Google requires it on your own page. Give it to Stratsol, which records it on your merchant, and Wasp Checkout presents it to Google for you: it is not in your code, and the checkout configuration's wallets.googlePay.merchantId carries it. Without one, Google Pay is not offered on your page in production. Hosted Checkout, and testing in the sandbox, are unchanged and need none. See Google Pay.

0.6.67 — 11 October 2026​

  • Every backend language is on the integration journey. Each path's backend pages, in Node.js, Python, Go, PHP, Java and C# / .NET, all show the same journey stage and Previous/Next. Only Node.js used to.
  • One name for every backend page. Each is titled for its area and language, such as "Hosted Checkout backend: Go", and listed as "Backend: Go".

0.6.66 — 10 October 2026​

  • Register opens the sign-up form, not the sign-in screen.
  • Signing in returns you to the page you were on, including a public documentation page. Opening an API reference, or your portal home, while signed out explains why an account is needed and brings you back after signing in.
  • A refused API reference says how to get access, as a refused documentation page already did.
  • Embedded Checkout. The Checkout quickstart now starts with what your backend tells the browser for each answer Wasp can give, and what to read first when Wasp refuses a request.
  • Checkout configuration. features.threeDS, and the SDK's capabilities().threeDS, now say whether Wasp can authenticate a payment that requires it in that environment; they were always false. Where it is false, such a payment is refused with 400. Neither says whether a particular payment will authenticate; the payment response does.
  • Developing on your own machine. Outcome notifications now shows how to receive notifications through a tunnel to your machine, how to check it works, and what to do when the tunnel restarts at a new address.
  • Going live. Environments now says plainly that Stratsol normally promotes your sandbox merchant to production, which keeps your Merchant ID and Aggregator ID and issues new credentials.
  • Sandbox authentication. A sandbox merchant can have an authentication policy; ask Stratsol whether yours does. Asking for authentication on a payment works either way.
  • Navigation. The integration journey names a step you cannot open yet, and what it needs, instead of linking to it; the wallet testing pages are no longer steps on one path only. Unknown portal addresses show a page you can navigate from. Links in text are underlined, and portal pages have a skip link.

0.6.65 — 9 October 2026​

  • What your business provides. Before you begin now lists what your business, and an aggregator, gives Stratsol to set you up: business name and address, contacts, the cardholder support phone number, the settlement bank account and the report email address.
  • Requesting access to a merchant may take you briefly through the sign-in page so Wasp can confirm it is you. Usually you type nothing.
  • Customer authentication. The guides say plainly that Stratsol manages your merchant's authentication policy, and that only stepUpRequested: true changes anything: sending false, or leaving it out, does not switch the policy off. The Google Pay pages state that PAN_ONLY payments follow the same 3D Secure rules as card payments.
  • Administering users. Approving an access request starts with Merchant API reference ticked. Global administrators see every merchant's pending requests first, and can delete a user with their sign-in; a global administrator cannot be deleted.
  • Operator guides. Stratsol's operators have guides to onboarding merchants and aggregators.
  • The visibility model no longer says the portal shows your payment methods or whether your outcome callback is set; it does not.
  • The privacy notice describes the internal notifications Stratsol receives about portal accounts.

0.6.62 — 6 October 2026​

  • A reference in progress is a duplicate. A payment sent with the reference of a payment that is still waiting for its customer to authenticate, or still being completed, is refused with 409. Look that payment up by its reference instead of sending it again.

0.6.61 — 5 October 2026​

  • Where your colours appear. Branding now lists where Hosted Checkout uses your primary and secondary colours, and which buttons never take them.
  • Your colours in every theme. A Hosted Checkout registered with theme: light or theme: dark now shows your colours, as a system checkout already did. The card Pay button darkens or lightens in your colour on hover and press.
  • Web channel only. The checkout configuration reports channels.inApp: false for every payment method, because payments are accepted from the web channel only.

0.6.60 — 4 October 2026​

  • Which test card to use. Test payments opens with a short chooser, and Testing Apple Pay lists Apple's sandbox test cards and how to add one to Wallet. Searching for "test cards" finds Test payments first.
  • Google Pay™ requirements. The Google Pay page sets out what Google requires of you on Hosted Checkout, links Google's terms and acceptable use policy, and says when a Google Pay payment can be authenticated.
  • SDK reference. A new page lists every public method, option and event. paymentComplete, paymentCompleteCallbackError, paymentMethodUnavailable and getSummary() are now documented.
  • SDK fixes. Apple Pay addresses now have the same shape as the other methods, a customer can try again after a failed submission, and mounting again starts a clean payment area.
  • Hosted Checkout. Buttons in your primary colour keep it on hover and press, and a branding change reaches an open checkout when the customer reloads it. A lookup with no payments is final only once the checkout has ended or expired.
  • Card fields run in your page. Card entry and Security boundaries say what that means for the scripts you load and your Content Security Policy. The Theme page says what theme controls.
  • The Direct backends run one payment by default and no longer print raw response bodies. A 200 without a payment is looked up once, never treated as a decline.
  • Card checks in the sandbox. The eftpos test host declines card checks, so you cannot complete a PreAuth on the eftpos route there.
  • Apple Pay trademark credit added to the Terms of use.

0.6.58 — 3 October 2026​

  • Examples show your own merchant. When your account is attached to a merchant, the guides fill in your Merchant ID, Aggregator ID, Checkout Web Domains and return profiles. If it is not attached yet, they tell you so and explain where each value comes from. Secrets are never shown.
  • Two API references. The Merchant API reference and the Wasp API reference are the complete contracts, each with an exact YAML download. The public API reference pages are retired. Guides link straight to the exact operation.
  • Test cards by route. Test payments now lists the test card for each acquiring route and the result each one gives.
  • Completing a PreAuth with an Advice is now documented.
  • Card on file, set up correctly. A series starts with a payment marked initial and recurring that carries the card security code. A later payment names that payment's reference in initialReference.
  • Merchant ID, one name, everywhere. Environments explains when your production Merchant ID matches your sandbox one.
  • Corrected error guidance. 401, 404 and validation errors are described as they actually happen.
  • Search finds codes such as 05 and W1, and field names.
  • Light and dark themes. Choosing light on a dark device now gives you light pages. The phone menu offers Docs and Search.

0.6.57 — 2 October 2026​

  • Google Pay: a closed sheet is reported as googlePayCancel, not as silence, so your page can offer its other payment methods again. A failed collection is still reported as error.
  • Apple Pay: the SDK asks Apple about the merchant your checkout configuration names (wallets.applePay.merchantIdentifier), unchanged.
  • No change to how you integrate.

0.6.55 — 1 October 2026​

  • One Onboarding section, in the order you meet it: before you begin, what Stratsol and you provide, registering and access, sandbox setup, wallet testing and production preparation.
  • Access comes in a set order. Stratsol sets up your sandbox merchant first; you register, request access with that Merchant ID, and an administrator approves it.
  • Client-owned Card and Google Pay do not use Checkout Web Domains. Only Embedded Checkout, and Apple Pay on your own page, need your page's origin authorised.
  • Wallets for production. The wallet pages list what each test needs, who registers what with Google and Apple, and what a production integration needs — without Stratsol's rollout status.
  • A lookup now says whether a payment has finished. Each entry in a lookup's payments carries a status. Incomplete or InProcess means Wasp has the payment and has not finished it: its approved: false, and any responseCode, are not its outcome yet. Every other status is final. The runnable examples read status before approved.

September 2026 — 0.6.3 to 0.6.53​

Breaking changes to Embedded Checkout

  • create({ waspBaseUrl, paymentContext }) is the whole initialiser. merchantId, transaction and environment are gone; Wasp resolves the merchant, order and payment methods from the paymentContext your server obtains when it starts the checkout.
  • One lifecycle object is passed to every mount call. mount() and mountApplePayButton() refuse without submitInstrument.

Payments and the API

  • amount is a JSON number in requests and a string in responses. reference comes back lowercased, is unique per order, and is shared by the sale and every transaction after it. Recurring payments are separate orders linked by initialReference.
  • A status lookup never answers 404; an unknown reference returns 200 with no payments. The order-level answer is balance, not the last entry in payments.
  • A 202 means Wasp accepted a payment it has not decided. Read status: authentication_required carries an action for the customer; processing carries none, because Wasp is authenticating without them. Keep the action.url from the first 202, and never resubmit an accepted payment.
  • Every accepted payment finishes with the signed outcome notification, which is sent once with no retry and is the result. Verify it, then act on the body. Polling is not taught anywhere; each flow states its lookup budget.
  • A failed authentication is a final decline with responseCode W1. Codes starting with W are Wasp's own: nothing was charged, and a retry needs a new reference. An abandoned payment returns no payments at all.
  • Published transaction names match the request vocabulary exactly. Requesting authentication where it cannot apply goes ahead unauthenticated with a 200.

Integrations

  • Direct Payment API added, for when you already hold the card or a stored credential, with card on file. Client-owned collection added, with client-owned Apple Pay and Google Pay. Runnable backends in all six languages, every one compiled and run.
  • Hosted Checkout ends on the Wasp page, which offers a link back that the customer may never follow. Build for the customer who never returns: a lookup by reference, or the outcome notification, decides the order. Hosted never needs an outcome callback, and can require authentication per order with stepUpRequested: true.
  • The SDK finishes a payment accepted without the customer (supply observePayment), locks drop-in controls while a payment is in flight, emits cancelled, and carries responseCode and responseDescription to your page.
  • Google Pay in the sandbox uses Google's TEST environment and needs no Google Merchant ID.

The sandbox

  • The amount does not decide whether a payment is approved; your test card does. The amount decides only the customer-authentication journey (without the customer, with them, or in the background), and an odd whole-dollar amount fails authentication. Test payments sets out the bands.
  • A Checkout Web Domain is your page's browser origin, so localhost:3000 works there; an outcome callback can never be localhost.

The portal

  • The Terms of use and Privacy notice are published, effective 21 September 2026.
  • A guided integration journey, one shell for every page, and a light | dark | system theme.
  • Each protected page is opened by exactly one kind of access, and no access gives you another; attachment to a merchant opens nothing on its own. Seven pages are open to registered developers so you can prepare before requesting access.
  • Portal search matches only pages you may read. A profile page lets you correct your own name.

0.6.2 — 30 August 2026​

  • The wallet buttons are logo-only and share one control shape.
  • Apple Pay added, in Safari and beyond it.
  • Registration is self-service and open. It verifies your email address and grants nothing further.
  • You can request access to a merchant from inside the portal, for an administrator there to approve.
  • Registration proves identity, merchant attachment establishes the organisational relationship, and access is granted separately. None of the three implies another.

0.5​

  • Portal review release. The integration guides, the API reference structure and the first Embedded Checkout SDK, as shared for early feedback.

Earlier​

Before 24 August 2026 the portal was being built and was not open to developers.

Last updated on