Omno API reference: endpoints, authentication and statuses

The Omno API lives at https://api.omno.com and uses OAuth 2.0 client credentials: send the access token as a Bearer token on every request. It covers customers, hosted checkout sessions, pay-ins, pay-outs and their manual approval, transaction status lookups and your enabled providers. Webhooks report final outcomes.

Updated

On this page5 sections

How do I authenticate?

With OAuth 2.0 client credentials. Create a Client ID and Client Secret in the dashboard under Developers, API Credentials, exchange them for an access token at https://sso.omno.com/realms/omno/protocol/openid-connect/token, and send it on every request:

Authorization: Bearer <access_token>

All requests go to https://api.omno.com. See Getting started for the full token request.

Which endpoints are available?

AreaEndpointPurpose
CustomersPOST /public/customerCreate or update a customer and their KYC data
Hosted checkoutPOST /public/cashier/sessionCreate a hosted checkout session
Pay-inPOST /public/payinCreate a pay-in
Pay-in, Direct LinkPOST /public/payin/{id}/process/direct-linkProcess a Direct Link pay-in and get the redirect URL
Transaction infoGET /public/payin/{id}Status and details of a pay-in
Transaction infoGET /public/payout/{id}Status and details of a payout
Pay-outPayout endpointsCreate and process pay-outs
Payout approvalConfirm or Reject PayoutApprove or reject payouts waiting for manual confirmation
ProvidersPSP endpointRead the providers enabled for your merchant account

Which statuses can a transaction have?

StatusMeaning
SUCCESSCompleted successfully
PENDING, PENDING_3DSWaiting; the final status follows by webhook
DECLINEDDeclined by the provider
FAILEDProcessing failed before or at the provider
TIMEOUTNo final answer from the provider in time
WAITING_FOR_CONFIRMATIONPayout waiting for your manual confirmation

Statuses can arrive out of order. Never overwrite a final status with an earlier one; see Webhooks.

Which fields shape routing?

customer.customerGroups, customer.kyc.kycLevels, kycVerified and previousTransactionCount on hosted checkout session, pay-in and payout requests, plus at most one of routerId or directRouteId. The routing and PSP eligibility guide explains each one.

How do I keep my integration safe?

Keep credentials and tokens on your backend, treat the checkout token as opaque and never log it, take final statuses only from webhooks or the transaction endpoints, and ignore transactions from fake providers in your balance logic.

Frequently asked questions

Is there a separate test API?

No. There is one production API. You test against fake payment providers configured on your account, as described in Getting started.

How do I check a transaction's final status?

Call GET /public/payin/{id} or GET /public/payout/{id}. Together with webhooks, this is the authoritative source for a transaction's status.

How are payouts approved manually?

A payout that needs approval waits in WAITING_FOR_CONFIRMATION until you confirm or reject it through the Confirm or Reject Payout endpoint.

How do I authenticate?

Exchange your Client ID and Client Secret for an access token at the OAuth 2.0 token endpoint, then send Authorization Bearer with the token on every request.

esc
↑↓ to move ↵ to open All results