Skip to main content
Soap provides payment, compliance, and fraud prevention APIs for merchants, platforms, and processors operating complex or compliance-heavy payment flows.
If you are utilizing AI coding tools such as Cursor, head over to our Soap MCP Server page to learn how to one-shot implement our Soap integration with AI!

​
API Overview

The Soap API is organized around REST. Our API has predictable resource-oriented URLs, accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs. A payment involves three distinct entities — the checkout the customer completes, the charge representing each payment attempt, and an optional review. Checkouts, Charges and Reviews explains how they relate, the charge status lifecycle, and why one checkout can have several charges.

​
Getting Started

Soap onboarding is invite-only — there’s no public self-serve signup. To get started with the Soap API, you’ll need to:
  1. Request access to get a Soap account set up
  2. Get your API keys from the dashboard
  3. Make your first API request
Check out our Quickstart Guide to make your first API call.

​
Authentication

Every Soap API request is authenticated with a bearer token sent as Authorization: Bearer <credential>:
Both credentials below are sent the exact same way — the only thing that changes is which credential you put after Bearer . Soap’s dashboard issues two separate credentials, and using the wrong one for an endpoint will fail:
GET /api/v1/device_pings/latest_geo_check uses your API key, not the client secret, even though it lives right next to POST /api/v1/device_pings in the same resource group. Mixing these up is a common mistake — the two endpoints intentionally use different credentials.
Requests with a missing or invalid credential return 422 with a JSON error field describing which credential was rejected:
Don’t confuse the business client secret above with the unrelated client_secret field returned in the POST /api/v1/checkouts response body (and used in the wallet URL, e.g. ?clientSecret=...). That per-checkout value identifies a single checkout session for the wallet — it is not an Authorization credential and is not the same secret discussed here.