Webhooks let Axra push payment events to your server the moment they happen, so you never need to poll the API to check whether a payment succeeded. When a payment event occurs — a charge completes, a dispute opens, or funds settle — Axra sends an HTTP POST request to theDocumentation Index
Fetch the complete documentation index at: https://docs.useaxra.com/llms.txt
Use this file to discover all available pages before exploring further.
webhookUrl you configured in your business profile. Because many payment flows (like 3DS redirects or card network clearing) are asynchronous, you should always confirm payment status through webhooks rather than relying solely on the response from a charge request.
Configure your webhook URL
Set your webhook endpoint in the Axra dashboard under Settings → Business Profile, or update it programmatically:Your webhook URL must be publicly reachable. During local development, use a tool like ngrok to expose your local server.
Event types
Axra delivers the following events to your webhook endpoint:| Event | Description |
|---|---|
payment.completed | Payment captured successfully |
payment.failed | Payment processing failed |
payment.settled | Funds cleared and available for withdrawal |
payment.refunded | Payment has been refunded |
payment.disputed | A dispute (chargeback) has been opened |
payment.dispute_won | Dispute resolved in your favor |
payment.dispute_lost | Dispute resolved against you |
collection.created | A local-rails collection was created. |
collection.processing | Funds have been detected, settlement is in progress. |
collection.completed | Funds settled; merchant USDC wallet credited. |
collection.failed | Collection failed (e.g. amount mismatch, provider rejection). |
collection.expired | Virtual account expired without payment. |
Webhook payload structure
Every webhook request shares the same envelope format:data object varies by event type. Below are the payloads for each event.
payment.completed
payment.completed
Fires when a payment is captured successfully. Update your order status to reflect payment received.
payment.failed
payment.failed
Fires when payment processing fails. The
reason field contains the failure code.payment.settled
payment.settled
Fires when funds have cleared the card networks and are credited to your merchant wallet (minus fees).
payment.refunded
payment.refunded
Fires when a refund is issued for a payment.
payment.disputed
payment.disputed
Fires when a cardholder opens a dispute (chargeback). The full charge amount is debited from your account immediately, plus a non-refundable dispute fee.
payment.dispute_won / payment.dispute_lost
payment.dispute_won / payment.dispute_lost
Fires when a dispute is resolved. If you win, the charge amount is re-credited to your account (the dispute fee is not refunded). If you lose, no further changes occur — the funds were already debited.
collection.created
collection.created
Fires immediately after a collection is created through the direct API or hosted checkout.
data.object mirrors GET /business/collections/{id}.collection.processing
collection.processing
Fires when inbound funds are detected and settlement is in progress.
collection.completed
collection.completed
Fires when the collection settles and your USDC wallet is credited. Fulfill the order on this event.
collection.failed
collection.failed
Fires when the provider reports a terminal failure (for example, amount mismatch or rejection).
collection.expired
collection.expired
Fires when deposit instructions expire before payment arrives.
Webhook request headers
Axra includes these headers on every webhook request:| Header | Description |
|---|---|
Content-Type | application/json |
X-Axra-Signature | HMAC-SHA256 signature of the raw request body |
X-Axra-Event | The event type (e.g., payment.completed) |
Signature verification
To verify a webhook:Get your webhook secret
Find your
webhookSecret in the Axra dashboard under Settings → API Keys. Store it as an environment variable — never hardcode it.Compute the expected signature
Compute an HMAC-SHA256 digest of the raw request body (the bytes as received, before any JSON parsing) using your
webhookSecret as the key.Compare using constant-time equality
Compare the computed digest to the value in the
X-Axra-Signature header using a constant-time comparison function. This prevents timing attacks.Use the raw request body bytes for signature computation — not a re-serialized version of the parsed JSON. JSON serialization is not guaranteed to be deterministic, and any whitespace difference will cause verification to fail.
Retry policy
Axra considers a delivery successful when your endpoint responds with an HTTP2xx status code within 30 seconds. If delivery fails, Axra retries with the following schedule:
| Attempt | Delay after failure |
|---|---|
| 1 | Immediate |
| 2 | 30 seconds |
| 3 | 60 seconds |
| 4 | 90 seconds |
| 5 | 120 seconds |
Best practices
- Return
200quickly — acknowledge receipt immediately, then process the event in a background job. Long-running handlers risk timeouts and unnecessary retries. - Handle duplicates — network retries mean your endpoint may receive the same event more than once. Use
paymentIdas an idempotency key to ensure you process each event exactly once. - Always verify signatures — reject any request where
X-Axra-Signaturedoes not match your computed value. - Use HTTPS in production — plain HTTP webhook URLs are rejected for live-mode credentials.
- Use ngrok during local development — run
ngrok http 3000to get a public URL that tunnels to your local server.
