Skip to main content

Where Wasp Checkout fits

Most merchants should not build their own shopping platform. Product catalogues, carts, inventory, shipping, promotions, and order management are usually handled by ecommerce platforms such as Shopify, WooCommerce, BigCommerce, Magento/Adobe Commerce, or by the merchant's own application. Wasp Checkout sits below that layer. It starts when the customer is ready to pay.

A merchant shopping experience and a payment acceptance layer are different layers. Wasp Checkout does not try to be the first. It is the second: the payment acceptance layer your commerce platform or application calls to take the payment.

The layers​

Merchant shopping experience
Shopify / WooCommerce / custom app / mobile app
  -> Wasp Checkout hosted page or browser SDK
    -> Wasp payment APIs
      -> acquirer / payment network / wallet / payment processing path

Your commerce platform owns everything up to the moment the customer is ready to pay. From that moment, Wasp Checkout collects the payment and Wasp executes it, and the result is returned to your systems for correlation by reference.

Wasp Checkout is not a shopping cart​

Wasp Checkout does not own, replace, or manage:

  • product catalogue
  • cart
  • inventory
  • shipping
  • promotions
  • customer accounts
  • order management

Those stay in your commerce platform or application. You keep whatever you already use for the shopping experience. Wasp Checkout is not competing with it.

Wasp Checkout owns secure payment collection​

Wasp Checkout is responsible for the payment acceptance layer:

  • payment-session registration
  • secure payment collection
  • wallet launch and configuration
  • card and wallet instrument handling
  • 3DS and browser security flows where applicable
  • payment authorization
  • payment status
  • returning the outcome to the merchant, correlated by reference

This is a narrow, deliberate responsibility. Wasp Checkout helps merchants accept payments securely through Stratsol's Wasp payment infrastructure, and nothing more.

Two ways to use Wasp Checkout​

Wasp Checkout is the tooling for the integrations where Wasp collects:

  • Hosted Checkout — the customer is redirected to the Wasp Hosted Payment Page, where Wasp provides the complete payment experience.
  • Embedded Checkout — the customer stays on the merchant page; the merchant's backend starts the checkout and the page loads the Wasp Checkout SDK with the resulting paymentContext, drop-in or headless.

A merchant that wants to keep collecting for itself uses neither: that is client-owned collection, which loads no Wasp browser code and reaches the same payment contract.

Card, Google Pay, Apple Pay, and 3DS are not integration options. They are payment methods, instruments, or security flows available inside all of them, subject to merchant configuration, browser and device capability, and Wasp support. See Choose your integration and the Wasp Checkout overview for the full model.

Hosted Checkout — the lowest-effort integration​

The Wasp Hosted Payment Page (Hosted Checkout) is for merchants who want the simplest and safest integration. The merchant backend registers a checkout session, then redirects to or launches the Wasp-hosted payment experience. This reduces the amount of sensitive payment UI the merchant has to build and keeps the payment ceremony consistent. Payment credentials are collected on the Wasp-managed page, not in the merchant's own frontend.

Embedded Checkout — for custom checkout UX​

The browser SDK (Embedded Checkout, drop-in or headless) is for merchants who want to keep the customer inside their own checkout page while still using Wasp Checkout to launch supported payment methods and normalize payment instruments. It suits custom web checkout experiences, single-page apps, embedded wallet buttons, and merchants with stronger frontend requirements. The SDK collects a normalised instrument in the browser; the merchant backend commits it with server-side credentials.

Why this exists alongside Shopify and WooCommerce​

A merchant may use Shopify, WooCommerce, or another platform for the shopping experience and still need a payment provider and acquirer integration. Wasp Checkout is that reusable payment acceptance layer. It can be plugged into different commerce environments without each one re-implementing secure payment collection.

In future, platform-specific integrations — such as a WooCommerce plugin or a Shopify-compatible integration — may sit above Wasp Checkout. Those integrations are adapters to the same core Wasp Checkout payment layer. They are not separate products, and they do not change the layering described here.

How to position Wasp Checkout​

Wasp Checkout is comparable in role to the hosted checkout and payment components offered by payment providers. It is not a competitor to ecommerce platforms.

It competes in the payment acceptance layer, not the shopping-cart layer. If you already have a shopping experience, Wasp Checkout is the piece you add to accept payments through Wasp — not a replacement for the systems you use to sell.

What Wasp Checkout does not do​

Wasp Checkout does not:

  • run your product catalogue, cart, or inventory
  • calculate shipping, tax, or promotions
  • manage customer accounts or your order lifecycle
  • store or own your commercial order data beyond the payment reference
  • replace your ecommerce platform, storefront, or mobile app
  • introduce a separate payment identifier — the merchant reference is the payment identity for correlation and verification

Everything above the payment line stays in your commerce platform or application. Wasp Checkout starts when the customer is ready to pay, and hands the outcome back to you by reference.

Last updated on