Create a payment from your server

The server API is for a partner whose application knows its own user: a payment is created from your server, with no button or panel on a page, and the user's state (subscriptions and purchases) is read by your own account reference. The key is the same as for the access check (API key tab in the cabinet), sent as Authorization: Bearer; the partner is identified by the key, there is no partner parameter. Rate limits are the same as for the access check: per your server's address and per key. Responses are JSON only and never cached. You can ask only about your own products and buyers: a foreign product or buyer and a non-existent one answer alike.

POST /api/v1/checkouts creates an order and returns the address to send the user to. The product is named by its id from the cabinet catalog; your account reference for the user is required, since without it the payment cannot be credited to anyone. From there everything works as for a widget purchase: the order.paid webhook with that reference, the result page, the return to your site.

Request

POST https://app.norelio.eu/api/v1/checkouts
Authorization: Bearer {api key}
Content-Type: application/json

{
  "productId": "prod_1a2b3c",
  "clientReference": "acc_10294",
  "customerEmail": "buyer@example.com",
  "returnUrl": "https://pawclaw.com/thank-you",
  "buyer": {
    "ip": "203.0.113.7",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64)"
  }
}

curl -s -X POST "https://app.norelio.eu/api/v1/checkouts" \
  -H "Authorization: Bearer $NORELIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"productId":"prod_1a2b3c","clientReference":"acc_10294","customerEmail":"buyer@example.com","returnUrl":"https://pawclaw.com/thank-you","buyer":{"ip":"203.0.113.7","userAgent":"Mozilla/5.0 (X11; Linux x86_64)"}}'

Response

201 Created with these fields:

{
  "id": "ord_7k3m2p",
  "url": "https://pay.lis-system.eu/api/public/checkout/continue?order=ord_7k3m2p&key=k4Xw1QmR9zL2nT8vB0cY7pH5sJ3eF6gD",
  "expiresAt": "2026-03-14T10:26:53.000Z",
  "clientReference": "acc_10294",
  "warnings": []
}

Open the url from the response in the user's browser as a normal navigation (a link or a redirect), not as a request from your server: the page at that address issues the buyer's receipt key, stores it in a cookie — as the checkout panel and direct checkout do — and forwards them to the payment provider. The address is SINGLE-USE: it carries a separate handoff key that is spent on the first open; a second open is refused. The receipt key never travels in the address — it is issued in the buyer's browser. Show the address to that user only and do not write it to logs: whoever opens it first receives the receipt key. The address expires at expiresAt. The result page and the return to your site after payment work as with direct checkout; on the Stripe page a line under the pay button links to the purchase terms.

Warnings

{
  "id": "ord_7k3m2p",
  "url": "https://pay.lis-system.eu/api/public/checkout/continue?order=ord_7k3m2p&key=k4Xw1QmR9zL2nT8vB0cY7pH5sJ3eF6gD",
  "expiresAt": "2026-03-14T10:26:53.000Z",
  "clientReference": "acc_10294",
  "warnings": [
    {
      "code": "return_url_rejected",
      "message": "returnUrl was ignored: it is not an https address on one of the return sites allowed for your account. The payment was created without a return address."
    }
  ]
}

Repeated calls and limits

A repeated call with the same data creates a NEW payment rather than returning the previous one: there is no idempotency. Orders the user never paid are removed by Norelio's nightly cleanup; they never enter payouts or the customer state.

On top of the per-address and per-key limits, the payment-attempt limit per buyer address — the same one the panel and the button use — applies when you pass buyer.ip. Without buyer.ip no per-buyer limit is counted: the request's address is your server's.

Errors

An error from any API endpoint is JSON of one shape: an error object with code (one of the codes below) and message (a short English sentence). A 429 response carries a Retry-After header. The access check keeps its own, older error shape.

{
  "error": {
    "code": "direct_checkout_not_enabled",
    "message": "Creating payments from your server is enabled after the platform has reviewed your purchase terms. Ask support from the cabinet's Messages section."
  }
}

The whole flow

How it fits together for an application with a subscription:

1. The user presses "Pay" in your application. Your server calls the create-payment endpoint with productId, your account reference for the user and, when known, the user's email, IP address and browser.
2. Send the user to the url from the response as a normal browser navigation. They pay on the provider's page, land on the Norelio result page and, with the return enabled, come back to you.
3. Your server receives the order.paid webhook with paymentId (the id from the response) and clientReference — your account reference. Verify the signature and credit that account.
4. When the user comes back, ask the customer state by clientReference, or the access check by product: both already account for renewals, refunds, grace and closed access.

The webhook is described in Webhooks, the state in Customer state, the access check in Access check.