Getting started with the Omno API: onboarding, credentials and testing

To start with Omno you get a merchant account, create a Client ID and Client Secret in the dashboard, exchange them for an OAuth 2.0 access token and call the API at api.omno.com. There is one production environment: you test with fake payment providers on your own account, then Omno swaps them for live providers when you go live.

Updated

On this page5 sections

How does onboarding work?

Onboarding takes eight steps, from the first conversation to live traffic:

  1. Contact Omno. Tell us your markets, methods and current providers.
  2. Account created. Omno creates your merchant account and gives you dashboard access.
  3. Choose your integration. The hosted checkout, or your own checkout with Card Fields for cards and Direct Links for local methods, wallets and crypto. The older Payment Page is not available to new merchants.
  4. Generate API credentials. In the dashboard, go to Developers, API Credentials and create a Client ID and Client Secret.
  5. Configure providers and routing. Payment providers and routers are set up for your account.
  6. Integrate and test against fake payment providers, as described below.
  7. Configure and verify webhooks, including repeated and out-of-order deliveries.
  8. Go live. Omno removes the fake providers and activates your live ones.

Which hosts does the API use?

Three hosts cover everything:

HostUsed for
https://api.omno.comAll API requests
https://sso.omno.com/realms/omno/protocol/openid-connect/tokenOAuth 2.0 token endpoint
https://checkout.omno.comThe hosted checkout, and the baseUrl for the Web SDK

How do I get an access token?

Use the OAuth 2.0 client credentials flow. Your backend sends the Client ID and Client Secret to the token endpoint and receives an access token, then sends it on every API call:

POST /realms/omno/protocol/openid-connect/token
Host: sso.omno.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET
POST /public/cashier/session
Host: api.omno.com
Authorization: Bearer <access_token>

Keep the Client Secret and access tokens on your backend. They never belong in a browser or mobile app.

How do I test without a separate test environment?

You test in production with fake payment providers. Omno configures them on your account; in the dashboard they appear under Payment Providers, Add Provider as Fake Card Pay-In, Fake APM Pay-In, Fake Card Pay-Out and Fake APM Pay-Out. Authorise each one and check that it is active in your router. Test transactions are not charged, and Omno removes the fake providers when testing ends.

Test cards work only with the fake providers. Use expiry 12/29, CVC 123 and any cardholder name:

Card numberResult
4539148803436467Success
6011111111111117Failure before the provider
3782822463100053-D Secure challenge, with a simulated page to pick the result

To force a specific decline on a card, use the code as the CVC. For local methods, enter the same three-digit code in the recipient field:

CodeCard or method declinePayout decline
001General decline
002Not allowed
004Expired cardExpired
005Inactive or blockedInactive
011Insufficient fundsInsufficient funds
013Invalid card numberInvalid card number
015CVV check failed
016Invalid amount or currency
026FraudFraud
033Provider timeoutTimeout
034Provider rejectedRejected
040Service unavailableUnavailable

For payouts that need manual approval, test both confirming and rejecting them.

What must be true before go-live?

Run through this list with the Omno team:

  • Omno has removed the fake payment providers.
  • Live providers are configured and your routers are verified.
  • Webhook handling is verified, including repeated deliveries and statuses that arrive out of order.
  • Your balance logic ignores fake provider IDs.
  • Final statuses come only from webhooks or Get Transaction Info, never from redirects or browser events.

Frequently asked questions

Does Omno have a separate test environment?

No. Omno runs a single production environment. You test with real API calls that are routed to fake payment providers configured on your account, and test transactions are not charged or billed.

How do I authenticate API requests?

Create a Client ID and Client Secret under Developers, API Credentials in the dashboard, exchange them for an access token with the OAuth 2.0 client credentials flow, and send the token as a Bearer token on every request.

How do I tell a test transaction from a live one?

Test transactions carry the fake provider's ID in merchantPspId or processorPspId. Check it in the webhook or with Get Transaction Info, and never fulfil an order or change a real customer balance for a fake provider transaction.

Which integration should I build first?

The hosted checkout, opened with the Web SDK. It takes cards, Apple Pay, Google Pay, local methods and crypto on one page in your brand, and it is the recommended option for new integrations.

esc
↑↓ to move ↵ to open All results