Payments made simple.

What Wasp gives you

Wasp is a payments platform, not a single payment button. You integrate once and get the payment methods, checkout experiences and payment capabilities below — enabled for your merchant rather than rebuilt by you.

• Cards and digital wallets

  Take card payments, Google Pay and Apple Pay through the same integration. Wasp normalises every payment method into one instrument shape, so your server code never branches on how the customer chose to pay.

  Which methods a customer sees depends on what is enabled for your merchant, and on their browser and device.

• Checkout experiences

  Send customers to a Wasp-hosted payment page, or keep them on yours with the Wasp Checkout SDK — either as a drop-in that arranges the payment area for you, or as headless controls you position yourself.

  Drop-in and headless are two layouts of Embedded Checkout, not separate products.

• Or keep the checkout you already have

  Already collecting cards or wallets? Keep doing it. Wasp prepares each payment method server-to-server, you collect it your own way, and you submit the result to the same payment contract every other route ends at — with no Wasp code in your browser.

  Suits a payment service provider, or any merchant with a collection stack it means to keep. It is not a different API.

• Making the hosted page yours

  The Wasp-hosted payment page carries your trading name and your logo, so a customer who leaves your site still sees who they are paying. You set it once from your backend — upload the logo, state the name — and every hosted checkout after that uses it.

  Applies to Hosted Checkout, which is the journey that leaves your site.

• Extra security when it’s needed

  Sometimes a payment needs the customer to confirm it is really them — their bank may ask for it, or you may. Wasp runs that check as part of the payment journey and carries the payment on once it is done. You send the customer to a page Wasp gives you; you never choose an authentication service or build the screen yourself.

  The documentation calls this customer authentication. It runs end to end in the sandbox today; production availability is per merchant and environment — confirm yours at onboarding.

• A server-to-server Payment API

  Not every integration has a browser in it. Submit signed payments directly from your backend and get the same contract, the same result shape, and the same identifiers as every other route into Wasp.

• More than a one-off sale

  Refunds, pre-authorisations, voids and account verification are the same signed request with a different type. Each one belongs to an order — the sale and everything that follows it — which you identify with a reference of your own, unique within your merchant. The authoritative result is the one your server reads back — never a browser redirect.

• Reconciliation and support

  Every payment carries the reference you chose, so your records and Wasp’s line up without a translation table. Look an order up by that reference when a customer asks what happened, when you are reconciling a day’s takings, or on the rare occasion an answer was lost on its way to you.

  It is how you ask later, not how a payment finishes.

• Recurring and stored credentials

  Declare merchant-initiated, initial-in-series and credential-on-file context on each payment, so subscriptions and instalments are presented correctly.

  Wasp does not store the credential for you — you hold it, and tell Wasp how it is being used.

Card, Google Pay and Apple Pay are payment methods, not integrations you choose between. You decide once how much of collection Wasp owns — Hosted Checkout, Embedded Checkout, or your own — and the methods enabled for your merchant then appear inside it.