Skip to main content
Beyond direct transaction creation, the API supports callback orchestration and widget-driven payment redirects.

​
Callback Delivery

When a transaction includes callback_url, your application can receive asynchronous delivery attempts for transaction results. If you need to trigger delivery manually, use:
  • POST /api/transaction/{id}/callback for one transaction;
  • POST /api/transactions/callbacks for multiple transactions.

​
Batch Callback Retries

POST /api/transactions/callbacks accepts a tx_ids array with one or more transaction identifiers. Each item in the response includes:
  • status, either ok or error;
  • tx_id when available;
  • optional http_status, body, or error details.
This endpoint is useful for operational retries after temporary downstream failures.

​
Customer Redirects

Use GET /api/transaction/{id}/redirect when your application wants the backend to choose the correct success or failure destination for the current transaction state. Successful redirects return HTTP 302 with a Location header.

​
Widget Entry Point

GET /api/widgets creates a widget transaction and redirects the customer to the frontend payment page. Supported query parameters:
  • widgetId or widget_id
  • amount
The endpoint accepts either widget identifier spelling, but only one valid widget id is required.

​
When to Use Which Flow

  • use direct transaction creation endpoints when your backend controls project context and request signing;
  • use widget redirects when you want a lightweight hosted entry flow;
  • use manual callback triggers when you need replay or recovery tooling.
Pair this page with Errors and Operational Notes so callback and redirect failures are handled consistently.