/payments/sessions endpoints are administrative operations and require a Bearer token plus access to the order’s shop.
Lifecycle
1
Session
POST /orders creates an order and a payment session at the chosen provider. The response contains a redirectUrl to the payment page.2
Payment at the provider
The customer pays. The provider processes the transaction on its side.
3
Webhook
The provider sends a notification to
POST /payments/webhooks/{provider}/{shopId}/{webhookSecret}. The API verifies the signature and updates the order status. See Webhooks.Payment channels
The method and channel are passed in a single field, separated by a colon:blik, card, or pbl is supported by every provider.
Session lifetime
Expired sessions are marked and cleaned up periodically. Check status with
GET /orders/payment-status/{orderId}; it requires a Bearer token for a user who can access the shop. Buyers use the trimmed public status endpoint with the secret capability token returned at order creation.
Retrying a payment
If a payment failed or expired, an authenticated shop member can create a new session for that order:Free orders
When a discount reduces the amount to zero, the order bypasses the payment gateway and enters plugin fulfillment. The response containsfree: true, the current status, a statusToken, and the status-page URL. Delivery may wait for plugin connectivity or for the player to be online when the product requires it.
Payment providers
The list of supported providers and their configuration.