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.
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-Keysaved for the same payment attempt on every retry - ▸ Receive a signed
invoice.paidwebhook on success
# 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.
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.
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.