Documentation

Wownero checkout documentation & API reference.

wowcheckout.com generates invoices, detects Wownero payments using view-only access, and relays status events. Setup is explicit: bring your primary address and secret view key - never spend keys, never custody.

Customer → Merchant walletNo spend keys requiredOpenAPI schema available
Integration recipesCopy/paste examples for curl, Node, PHP, Python, and Go.

Start here

  1. 1) Sign in (view-only)

    Use your primary address + secret view key to retrieve an API key.

  2. 2) Create an invoice

    Call POST /api/core/invoices and redirect the customer to the hosted invoice URL.

  3. 3) Optional: configure webhooks

    Subscribe to invoice.confirmed to get status events pushed to your system.

  4. 4) Confirm and fulfill

    Wait for invoice.confirmed (webhook or polling). You can also check the public status endpoint, then mark your order paid.

Fiat inputs (optional)

You can request an invoice using a fiat amount. The backend converts the value to WOW using the current rate and returns a non-binding quote in the response. The invoice is always stored in WOW.

POST /api/core/invoices
Authorization: ApiKey <api_key>
Content-Type: application/json

{
  "amount_fiat": "100.00",
  "currency": "USD",
  "confirmation_target": 2,
  "checkout_continue_url": "https://merchant.example/thanks",
  "metadata": { "order_id": "ORDER-1234" }
}

Core principles

All behavior is constrained by non-custodial rules.

  • Merchants retain wallet access (your keys, your funds)
  • View-only access maximum
  • No fiat rails or execution of financial actions

Subaddress-only invoices

Every invoice uses a subaddress derived from your primary address for clearer reconciliation.

  • Subaddress index shown on each invoice
  • Wallet lookahead controls discovery
  • Subaddresses cycle through indices 1 to 100
  • Wallets may require adding the index to view funds

Invoice lifecycle

Clear state transitions without hidden automation.

  • Pending → Payment detected → Confirmed
  • Pending → Expired
  • Pending → Invalid (manual)

Authentication

Two auth modes keep integrations explicit and observable.

  • API key for authenticated endpoints
  • Primary address + secret view key to retrieve API credentials
  • Headers: Authorization: ApiKey <api_key>
  • BTCPay compatibility: Authorization: token <api_key>

Webhook events

Observable events for merchant systems.

  • invoice.created
  • invoice.payment_detected
  • invoice.confirmed
  • invoice.expired
  • Deliveries include the X-Webhook-Secret header
  • Webhooks are optional; poll /api/core/public/invoice/<invoice_id> without auth

Base URL

The API can be reached from:

  • https://wowcheckout.such.software/api/core

BTCPay compatibility (WooCommerce)

A Greenfield-compatible subset keeps the official WooCommerce plugin working without custodial behavior.

  • Base URL uses /api/v1
  • Supported endpoints: stores, invoices, payment methods, webhooks
  • Invoices are defined in WOW; fiat inputs are quote-only metadata
  • Modal checkout is supported; the hosted invoice page is recommended for clarity

BTCPay webhooks

Deliveries are signed with the BTCPay header format.

  • BTCPay-Sig: sha256=<hmac>
  • Event names follow BTCPay conventions for compatibility.

API reference

Every endpoint exposed by the API is listed below, grouped by access mode.

Login

Auth: None

1 endpoints
POST
/api/core/auth/loginExchange a primary address and secret view key for an API key and webhook secret.
Requirements
Required: payment_address, view_key
  • Primary address only; subaddresses and integrated addresses are rejected.
  • Use the secret view key (never submit a spend key).

Public invoice status

Auth: None

2 endpoints
GET
/api/core/public/invoice/{invoice_id}Read invoice status and payment details without auth.
Requirements
Required: invoice_id (path)
  • Returns invoice status and payment details.
GET
/api/core/public/invoice/{invoice_id}/continueAfter confirmation, redirect to the merchant-provided Continue URL (if configured).
Requirements
Required: invoice_id (path)
  • Only available after an invoice is confirmed.
  • Returns a 302 redirect to the merchant-provided checkout_continue_url (if configured).

Invoice workflow

Auth: API key

5 endpoints
GET
/api/core/invoicesList invoices for the signed-in user (supports search and sorting).
Requirements
Required: None
Optional: limit (default 50, 1-100), offset (default 0), status, include_archived (default false), q (invoice id, subaddress, metadata), sort (created_at, expires_at, amount_xmr, status, confirmations, confirmation_target), order (asc or desc), created_from (ISO timestamp), created_to (ISO timestamp)
  • Returns invoices excluding archived entries.
GET
/api/core/invoices/export.csvExport invoices as CSV (same filters as list endpoint).
Requirements
Required: None
Optional: include_archived (default false), status, q, sort, order, created_from, created_to
  • Returns CSV with invoice rows.
GET
/api/core/invoices/{invoice_id}Retrieve a single invoice for the signed-in user.
Requirements
Required: invoice_id (path)
  • Returns a single invoice (archived invoices are excluded).
POST
/api/core/invoicesCreate invoices for the signed-in user.
Requirements
Required: amount_xmr or amount_fiat + currency
Optional: confirmation_target (default 2, 0-10), checkout_continue_url (https URL, optional post-confirmation Continue button), metadata, expires_at (ISO 8601)
  • Fiat conversion is non-binding and does not lock a rate.
  • Creates a pending invoice and returns invoice details.
DELETE
/api/core/invoices/{invoice_id}Archive a pending invoice until it expires (payment-detected/confirmed invoices cannot be archived).
Requirements
Required: None
  • Only pending, expired, or invalid invoices can be archived. Returns 204 on success.

API key webhooks

Auth: API key

5 endpoints
GET
/api/core/webhooksList active webhook registrations.
Requirements
Required: None
  • Returns the most recent webhooks first.
GET
/api/core/webhooks/historyList recent webhook delivery attempts and HTTP status.
Requirements
Required: None
Optional: limit (default 50, 1-200), offset (default 0)
  • Returns the most recent webhook deliveries first.
POST
/api/core/webhooks/deliveries/{delivery_id}/redeliverManually redeliver a failed webhook delivery.
Requirements
Required: delivery_id (path)
  • Only failed deliveries can be redelivered.
POST
/api/core/webhooksRegister webhook URLs (single or per-event) and event filters.
Requirements
Required: events (at least one) or event_urls (at least one)
Optional: url, event_urls, events
  • Provide url for all selected events unless every event is mapped in event_urls.
  • Events must be one of: invoice.created, invoice.payment_detected, invoice.confirmed, invoice.expired.
DELETE
/api/core/webhooks/{webhook_id}Remove a webhook registration.
Requirements
Required: webhook_id (path)
  • Returns 204 on success.

API key management

Auth: API key

2 endpoints
POST
/api/core/api-credentials/resetReset the API key, webhook secret, or both.
Requirements
Required: reset_api_key or reset_webhook_secret
  • At least one reset flag must be true.
PATCH
/api/core/profileUpdate profile preferences like the BTCPay checkout layout or default confirmations.
Requirements
Required: None
Optional: btcpay_checkout_style, default_confirmation_target
  • Set btcpay_checkout_style to standard or btcpay_classic.
  • Applies to hosted invoice pages served for BTCPay compatibility.

BTCPay Greenfield stores

Auth: API key (token)

3 endpoints
GET
/api/v1/storesList stores accessible to the API key.
Requirements
Required: None
  • Single-store per user: the list returns one store.
  • Store ids map to the authenticated user id.
  • Header format: Authorization: token <api_key>.
GET
/api/v1/stores/{store_id}Retrieve a store by id.
Requirements
Required: store_id (path)
  • Only the authenticated store id is valid.
  • Returns the store metadata expected by Greenfield clients.
GET
/api/v1/stores/{store_id}/payment-methodsList enabled payment methods (WOW-CHAIN only).
Requirements
Required: store_id (path)
  • Returns WOW-CHAIN as the only enabled payment method.

BTCPay Greenfield invoices

Auth: API key (token)

4 endpoints
POST
/api/v1/stores/{store_id}/invoicesCreate a BTCPay-compatible invoice.
Requirements
Required: store_id (path), amount, currency
Optional: metadata, checkout
  • Fiat inputs are converted once at creation time and stored as metadata.
  • Invoices are defined and payable in WOW only.
GET
/api/v1/stores/{store_id}/invoices/{invoice_id}Retrieve a BTCPay-compatible invoice.
Requirements
Required: store_id (path), invoice_id (path)
  • Returns BTCPay-compatible status fields.
GET
/api/v1/stores/{store_id}/invoices/{invoice_id}/payment-methodsReturn payment details for the invoice.
Requirements
Required: store_id (path), invoice_id (path)
  • Read-only payment details derived from observed on-chain data.
  • Returns a list even when only one payment method is enabled.
POST
/api/v1/stores/{store_id}/invoices/{invoice_id}/statusMark an invoice as Invalid (compatibility only).
Requirements
Required: store_id (path), invoice_id (path), status
  • Only supports status=Invalid for compatibility; no funds move.

BTCPay Greenfield webhooks

Auth: API key (token)

5 endpoints
POST
/api/v1/stores/{store_id}/webhooksRegister a webhook with authorized events.
Requirements
Required: store_id (path), url, authorizedEvents
Optional: enabled, automaticRedelivery
  • Deliveries include BTCPay-Sig: sha256=<hmac>.
  • Events follow BTCPay naming conventions for compatibility.
GET
/api/v1/stores/{store_id}/webhooksList registered webhooks for a store.
Requirements
Required: store_id (path)
  • Returns the most recent webhooks first.
GET
/api/v1/stores/{store_id}/webhooks/{webhook_id}Retrieve a webhook by id.
Requirements
Required: store_id (path), webhook_id (path)
  • Returns a single webhook registration.
PUT
/api/v1/stores/{store_id}/webhooks/{webhook_id}Update a webhook (enabled, url, or events).
Requirements
Required: store_id (path), webhook_id (path)
Optional: enabled, automaticRedelivery, url, authorizedEvents
  • Updates a webhook registration.
DELETE
/api/v1/stores/{store_id}/webhooks/{webhook_id}Delete a webhook registration.
Requirements
Required: store_id (path), webhook_id (path)
  • Returns 204 on success.

BTCPay server info

Auth: API key (token)

2 endpoints
GET
/api/v1/server/infoReturn server info for compatibility checks.
Requirements
Required: None
  • Version is set for compatibility with refund UI behavior.
GET
/api/v1/api-keys/currentReturn the API key label and permissions.
Requirements
Required: None
  • Permissions are store-scoped strings tied to one store id.
  • Refund permissions are intentionally omitted.
Need the machine-readable schema?OpenAPI JSON