Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.pawpayments.com/llms.txt

Use this file to discover all available pages before exploring further.

The Compatibility API lets an existing merchant integration keep its provider SDK and request format while switching traffic to PawPayments. In most integrations, the merchant changes only the provider base URL:
Provider SDKPaw base URL
Cryptomushttps://api.pawpayments.com/compat/cryptomus/v1
Helekethttps://api.pawpayments.com/compat/heleket/v1
NowPaymentshttps://api.pawpayments.com/compat/nowpayments/v1
Use the same Paw merchant api_key for request signing. Cryptomus and Heleket SDKs send the Paw merchant ID as the merchant header and sign with api_key. NowPayments SDKs continue to send x-api-key.

Webhooks

Invoices created through a compatibility route automatically use that provider’s webhook format:
Created throughWebhook format
/compat/cryptomus/v1Cryptomus IPN body with sign in JSON
/compat/heleket/v1Heleket-compatible IPN body with sign in JSON
/compat/nowpayments/v1NowPayments IPN body with x-nowpayments-sig header
Native APINative format by default, or the invoice-level webhook_format override
Compatibility routes are documented here as a migration guide. For individual request field descriptions, keep using the original provider documentation. The sections below describe what Paw supports, what is ignored, and what returns 501 NOT_SUPPORTED.