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.
Start here
1) Sign in (view-only)
Use your primary address + secret view key to retrieve an API key.
2) Create an invoice
Call POST /api/core/invoices and redirect the customer to the hosted invoice URL.
3) Optional: configure webhooks
Subscribe to invoice.confirmed to get status events pushed to your system.
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
Requirements
- Primary address only; subaddresses and integrated addresses are rejected.
- Use the secret view key (never submit a spend key).
Public invoice status
Auth: None
Requirements
- Returns invoice status and payment details.
Requirements
- 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
Requirements
- Returns invoices excluding archived entries.
Requirements
- Returns CSV with invoice rows.
Requirements
- Returns a single invoice (archived invoices are excluded).
Requirements
- Fiat conversion is non-binding and does not lock a rate.
- Creates a pending invoice and returns invoice details.
Requirements
- Only pending, expired, or invalid invoices can be archived. Returns 204 on success.
API key webhooks
Auth: API key
Requirements
- Returns the most recent webhooks first.
Requirements
- Returns the most recent webhook deliveries first.
Requirements
- Only failed deliveries can be redelivered.
Requirements
- 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.
Requirements
- Returns 204 on success.
API key management
Auth: API key
Requirements
- At least one reset flag must be true.
Requirements
- 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)
Requirements
- Single-store per user: the list returns one store.
- Store ids map to the authenticated user id.
- Header format: Authorization: token <api_key>.
Requirements
- Only the authenticated store id is valid.
- Returns the store metadata expected by Greenfield clients.
Requirements
- Returns WOW-CHAIN as the only enabled payment method.
BTCPay Greenfield invoices
Auth: API key (token)
Requirements
- Fiat inputs are converted once at creation time and stored as metadata.
- Invoices are defined and payable in WOW only.
Requirements
- Returns BTCPay-compatible status fields.
Requirements
- Read-only payment details derived from observed on-chain data.
- Returns a list even when only one payment method is enabled.
Requirements
- Only supports status=Invalid for compatibility; no funds move.
BTCPay Greenfield webhooks
Auth: API key (token)
Requirements
- Deliveries include BTCPay-Sig: sha256=<hmac>.
- Events follow BTCPay naming conventions for compatibility.
Requirements
- Returns the most recent webhooks first.
Requirements
- Returns a single webhook registration.
Requirements
- Updates a webhook registration.
Requirements
- Returns 204 on success.
BTCPay server info
Auth: API key (token)
Requirements
- Version is set for compatibility with refund UI behavior.
Requirements
- Permissions are store-scoped strings tied to one store id.
- Refund permissions are intentionally omitted.
