A Stripe mock API that remembers, and calls you back

Connect

Import it. In Sonda: Import → From a URL, paste the OpenAPI address. You get a folder per resource and a request per operation, with example bodies and ids from the seed account, so each request works as it is. Then set the auth: Bearer token sk_test_sondahub. Any client that imports OpenAPI 3 takes the same address.

Stripe’s SDKs know nothing about sondahub’s sessions, so give them the few lines that carry X-Sondahub-Session from one answer to the next request — otherwise every call starts from the seed account and the customer you just made is “No such customer”.

Node (stripe-node)

import Stripe from 'stripe'

// carry the sandbox session from each answer to the next request
let session = null
const sessionFetch = async (url, init = {}) => {
  const headers = new Headers(init.headers)
  if (session) headers.set('X-Sondahub-Session', session)
  const res = await fetch(url, { ...init, headers })
  session = res.headers.get('X-Sondahub-Session') ?? session
  return res
}

const stripe = new Stripe('sk_test_sondahub', {
  host: 'api.sondahub.com',
  httpClient: Stripe.createFetchHttpClient(sessionFetch),
})

const customer = await stripe.customers.create({ email: '[email protected]' })
const pi = await stripe.paymentIntents.create({ amount: 2000, currency: 'usd', customer: customer.id, payment_method: 'pm_card_visa', confirm: true })

Python (stripe-python)

import requests, stripe

# carry the sandbox session from each answer to the next request
session = requests.Session()
def keep(r, *args, **kwargs):
    if 'X-Sondahub-Session' in r.headers:
        session.headers['X-Sondahub-Session'] = r.headers['X-Sondahub-Session']
session.hooks['response'].append(keep)

client = stripe.StripeClient(
    'sk_test_sondahub',
    base_addresses={'api': 'https://api.sondahub.com'},
    http_client=stripe.RequestsClient(session=session),
)

customer = client.v1.customers.create(params={'email': '[email protected]'})
pi = client.v1.payment_intents.create(params={'amount': 2000, 'currency': 'usd', 'customer': customer.id, 'payment_method': 'pm_card_visa', 'confirm': True})

The module-level style works too:

stripe.api_key = 'sk_test_sondahub'
stripe.api_base = 'https://api.sondahub.com'
stripe.default_http_client = stripe.RequestsClient(session=session)   # the session above

Try it here

curl https://api.sondahub.com/v1/customers \
  -u sk_test_sondahub: \
  -d "[email protected]" \
  -d "name=Ada Lovelace" \
  -d "metadata[plan]=pro"

curl https://api.sondahub.com/v1/payment_intents \
  -u sk_test_sondahub: \
  -d "amount=2000" \
  -d "currency=usd" \
  -d "payment_method=pm_card_visa" \
  -d "confirm=true" \
  -d "expand[]=latest_charge"

curl https://api.sondahub.com/v1/payment_intents \
  -u sk_test_sondahub: \
  -d "amount=2000" \
  -d "currency=usd" \
  -d "payment_method=pm_card_visa_chargeDeclinedInsufficientFunds" \
  -d "confirm=true"

curl "https://api.sondahub.com/v1/payment_intents?limit=3" -u sk_test_sondahub:

curl https://api.sondahub.com/v1/refunds \
  -u sk_test_sondahub: \
  -d "payment_intent=pi_1Sh1Kbwe5lqI1XPwHWwqG0O8" \
  -d "amount=500"

curl "https://api.sondahub.com/v1/events?limit=5" -u sk_test_sondahub:

From the shell, keep the token yourself: curl -i shows X-Sondahub-Session; send it back with -H "X-Sondahub-Session: …". How sessions work.

Test cards

Stripe’s own test numbers and test PaymentMethod ids, doing what Stripe documents them to do. Pass the pm_card_… id as payment_method (a new payment method is made from it), or the number as card[number] with any future expiry date and any CVC. A number that is not a test card is refused — never send a real one anywhere but Stripe.

How a payment moves

3D Secure. The authentication page stands in for the bank’s: approve or fail, and the browser returns to your return_url with payment_intent and redirect_status. The page can’t write to your session (the browser doesn’t carry your token), so the PaymentIntent waits in requires_action: on redirect_status=succeeded the server finishes it by confirming once more — where Stripe would have moved it to succeeded on its own — and on failed the server cancels it or confirms with another card (Stripe would have moved it to requires_payment_method). To test a card that authenticates and is then declined, use pm_card_threeDSecureRequiredChargeDeclined.

Errors. Card errors answer 402 with type: card_error, code, decline_code and the PaymentIntent inside; the rest answer 400 invalid_request_error naming the parameter — an unknown parameter, an amount under the currency’s minimum, a status that does not allow the call — or 404 resource_missing.

Webhooks

Register an endpoint and every event your calls cause is POSTed to it, signed with its secret the way Stripe signs: Stripe-Signature: t=…,v1=…. Deliveries go out within a second or two of the answer, retried after 1, 3 and 8 seconds when your endpoint can’t be reached or answers 408, 429 or a 5xx (any other answer is final).

curl https://api.sondahub.com/v1/webhook_endpoints \
  -u sk_test_sondahub: \
  -d "url=https://your-app.example/stripe/webhooks" \
  -d "enabled_events[]=payment_intent.succeeded" \
  -d "enabled_events[]=checkout.session.completed"

// Express: the raw body, not the parsed one
app.post('/stripe/webhooks', express.raw({ type: 'application/json' }), (req, res) => {
  const event = stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret)
  if (event.type === 'payment_intent.succeeded') fulfil(event.data.object)
  res.sendStatus(200)
})

Events: customer.created / updated / deleted · payment_method.attached / detached / updated · payment_intent.created / requires_action / amount_capturable_updated / succeeded / payment_failed / canceled / updated · charge.succeeded / failed / captured / refunded / updated · refund.created / updated · product.created / updated / deleted · price.created / updated · checkout.session.completed / expired. GET /v1/events keeps the last 30 of your session. For a one-off target, the hub-wide X-Sondahub-Webhook header on any call works too (the webhook tester).

Checkout

POST /v1/checkout/sessions (mode payment, line_items by price or price_data, success_url) answers a session whose url opens a test checkout page on sondahub — plainly a sandbox page, never a copy of Stripe’s. Paying sends charge.succeeded, payment_intent.succeeded and checkout.session.completed to the endpoints you had registered and sends the browser to your success_url, {CHECKOUT_SESSION_ID} filled in.

The browser’s payment does not reach your API session: retrieving the session afterwards still says open and unpaid, and the pi_ and ch_ ids in those three events can’t be retrieved. Fulfil from the event’s own payload — the paid session is in checkout.session.completed, which is how Stripe tells you to fulfil orders anyway.

What it answers

Lists take limit, starting_after, ending_before and, except /line_items, created; every call takes expand[], Idempotency-Key and Stripe-Version (echoed back). The seed account has 24 customers with cards, 8 products and 40 payments — succeeded, refunded, declined, canceled and held for capture.

Also on sondahub

Fake REST API · Public GraphQL API · gRPC-Web & Connect · WebSocket test server · SSE test server · Public MQTT broker · MCP test server · MCP OAuth test server · Writes that persist · OpenAPI mock server · Webhook tester · Chaos and rate limits · SAML test IdP and SP · SCIM 2.0 test server · OAuth 2.0 test server · Auth test endpoints · HTTP test endpoints · Fake JSON data · JSONPlaceholder alternative · Twilio sandbox

The mock APIs themselves: fake e-commerce API, fake IoT API, fake banking API, fake social media API, fake helpdesk API, fake flight booking API, fake user directory API. Built as the playground for LockFlare Sonda, the API client that lives on your computer.