Skip to content
Developers

Build on a typed REST API with signed webhooks

A focused HTTP surface for invoices, shops, and supported currencies — plus HMAC-signed webhooks for every state change. Idempotent writes, sandbox, and a detailed integration reference.

Quickstart

Create your first invoice

Create a shop with your website URL, save its signing secret, and issue a key with invoices:write (plus invoices:read for reconciliation and currencies:read for asset discovery). Create an invoice on your server and redirect to the returned paymentUrl.

  • ▸ Authorize with a per-shop X-API-Key
  • ▸ Pass an Idempotency-Key saved for the same payment attempt on every retry
  • ▸ Receive a signed invoice.paid webhook on success
create-invoice
# Set these on your server. Persist one idempotency key per payment attempt;
# reuse that key and the identical body when retrying that attempt.
curl --fail-with-body -X POST https://blupay.me/api/v1/invoices/ \
  -H "X-API-Key: $BLUPAY_API_KEY" \
  -H "Idempotency-Key: $BLUPAY_IDEMPOTENCY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "currencyAmount": "49.00",
    "currencySymbol": "USD",
    "orderId": "order-1024",
    "orderDescription": "Pro plan - monthly",
    "timeForPayment": 60,
    "redirectUrl": "https://merchant.example.com/thanks",
    "webhookUrl": "https://merchant.example.com/blupay/webhook"
  }'

Replace the example domain with your shop's registered website host (or its subdomain). API keys and signing secrets stay on your server. Save one idempotency key before the first request and reuse it with the same payload after a timeout; a conflicting or in-flight request returns 409. The webhook handler requires your durable inbox implementation. Its worker must match data.invoice_link, order_id, currency_amount and currency_symbol to the saved order using decimal-safe comparisons and fulfil once only for invoice.paid with status Paid. Handle duplicate events and reconciliation atomically.

Platform

Built for reliability and audit

Typed REST API

JSON over HTTPS. Consistent response envelope. The API reference describes request validation, required scopes, and response shapes.

Signed webhooks

Verify HMAC-SHA256(timestamp + raw_body), reject stale timestamps, and handle repeated events safely. Failed deliveries are retried.

Scoped API keys

Generate per-shop keys with explicit permissions and optional source IP allow-lists. Revoke unused keys and protect the plaintext credentials.

Sandbox

Create a Sandbox shop and use its API key for test invoices. Sandbox is a shop setting; a request flag cannot switch a live shop into test mode.

Idempotency

Use an Idempotency-Key for invoice creation and keep the same request body when retrying the same payment attempt. Check each endpoint’s retry contract.

Hardened auth

JWT access and refresh tokens, TOTP two-factor authentication, and AES-256-GCM encryption for stored authentication secrets.

Endpoints

A few of the core REST endpoints

Paths below are relative to https://blupay.me/api. See the reference for validation, scopes, and examples.

  • POST/v1/invoices/Create an invoice
  • GET/v1/invoices/List your invoices
  • GET/v1/invoices/{link}/Retrieve an invoice
  • GET/v1/shops/List your shops
  • GET/v1/currencies/{type}/Supported assets (crypto/fiat)

Build something

Create a shop, generate a sandbox API key, and test your invoice and webhook integration before enabling live payments.