/api/v2/* surface, plus plugins for popular billing and e‑commerce platforms. The PHP SDK underpins WooCommerce, WHMCS, Blesta, and BillManager; Python and Node clients mirror the full Native V2 API (invoices, payouts, ledger, permanent addresses, and more). Plugins use only public endpoints — no hidden backend logic — so anything they do is reproducible from your own integration.
Common conventions
All plugins are intentionally thin wrappers around the public API and follow the same conventions, so they can coexist on a single merchant account without colliding:extracarries the platform invoice / order ID for checkout flows, and the client / account ID for top‑up flows.metadata.sourceis set towhmcs,woocommerce,blesta, orbillmanager.metadata.flowischeckoutortopup.- Checkout and top‑up always use separate
notify_urlendpoints, so a single PawPayments callback URL setting on the merchant side is not required. - Currency and network selection happens entirely on the PawPayments paywall — the plugins never need to know which assets are enabled for the merchant.
Webhook handling
Every plugin verifies theX-Paw-Signature header (HMAC‑SHA256 of the raw body, keyed with the merchant’s API key).
Webhooks that carry a permanent_address_id field — i.e. deposits to long‑lived addresses, not to a one‑shot invoice — are silently acknowledged with 200 OK and never produce duplicate orders or credits. Permanent‑address flows belong to your own backend integration, not to a checkout plugin.
Idempotency
Each plugin protects against double‑credit on webhook retries:- WooCommerce —
payment_complete()is natively idempotent; the order can only transition out ofon-holdonce. - WHMCS — checkout uses
addInvoicePayment’stransactionIddeduplication; top‑up uses a smallmod_pawpayments_creditstable keyed byorder_id. - BillManager — checkout reads payment status before calling
payment.setpaid; top‑up checksexternalidbefore issuing a new payment.

