Crypto Payment API

Build payment flows without building blockchain monitoring from scratch.

Paxlivo gives merchants a hosted payment layer that can be connected to custom applications through APIs and payment events. Your application owns the customer and order workflow; Paxlivo coordinates the crypto invoice and payment state.

API-first workflow

Create an invoice, present checkout, receive a payment event.

The example below illustrates the intended merchant workflow rather than a final public endpoint contract. Production endpoint names, authentication requirements and event payloads will be documented as Paxlivo merchant API access is opened more broadly.

Scoped merchant credentials HTTPS API access Signed event notifications Server-to-server integration

Illustrative request

POST /api/invoices
Authorization: Bearer <merchant-token>
Content-Type: application/json

{
  "amount": 149.00,
  "currency": "USD",
  "orderId": "ORDER-1048",
  "callbackUrl": "https://merchant.example/webhook"
}

Invoice operations

Create a payment request from your application and retrieve its current state using credentials associated with the merchant store.

Payment events

React to detected and confirmed payments without relying on the customer browser to report success back to your application.

Scoped access

Separate merchant credentials and grant only the permissions required by each integration instead of sharing administrator credentials.

Production integration checklist

Build the payment flow as a state machine, not a single “paid” redirect.

A crypto transaction moves through multiple states. A robust integration should record the Paxlivo invoice identifier and treat server-to-server payment data as authoritative for fulfillment.

Authenticate safely

Store API credentials in server-side secrets, use the smallest practical permission scope and never expose merchant tokens in client-side JavaScript or public repositories.

Verify webhooks

Validate event signatures and associate the event with a known invoice before changing order state, issuing credits or provisioning service.

Make handlers idempotent

Webhook delivery can be retried. Processing the same event twice should not create a second order, duplicate credit or repeat a provisioning action.

Payment-state design

Keep “detected” and “confirmed enough to fulfill” separate.

Your application may learn that a transaction exists before it reaches the confirmation policy appropriate for the order. High-value products may use a different fulfillment threshold than low-risk digital orders.

The integration should also have an explicit path for expired, incomplete or exceptional payments instead of treating every non-success state as identical.

01Create invoiceSave the merchant order mapping

02Send customer to checkoutDo not expose API secrets

03Receive & verify eventsUpdate internal payment state

04Fulfill onceOnly after your configured policy is met

Testing

Run low-value real transactions before production rollout.

A sandbox can validate application logic, but blockchain integrations should also be exercised with controlled low-value transactions before you depend on them for customer orders. Verify the address, payment amount, status transition and webhook log from end to end.

Support boundaries

Never send recovery material in an API support request.

Support may need an invoice ID, store identifier, timestamp or sanitized request/response details. It should never require a seed phrase, private key or full wallet backup.

Documentation

Merchant API documentation will expand with beta access.

During early access, integration guidance will be provided alongside merchant onboarding while public documentation is finalized.

Documentation