canonical: https://jentic.com/apis/omise.co/omise

# Omise API

Jentic publishes the only available OpenAPI specification for Omise API, keeping it validated and agent-ready. The Omise API is a payment gateway widely used in Thailand, Japan, and across Southeast Asia for accepting card and alternative-payment-method charges, managing customers and saved cards, issuing refunds, and orchestrating transfers to merchant bank accounts. It exposes 44 endpoints covering charges (with capture/reverse/expire actions), customers and stored cards, tokens, refunds, transfers, recipients, sources for alternative payment methods, and account balance reads. Authentication uses HTTP Basic with a secret key on api.omise.co and a public key on vault.omise.co.

## For AI agents

Process card and APM payments across Southeast Asia with Omise - create charges, manage saved cards, issue refunds, and transfer settled funds to merchant accounts.

## Scope

Does not handle accounting reconciliation, tax filing, or KYC onboarding - use for payment acceptance, refunds, and merchant transfers only.

## Capabilities

- Create authorised or captured card charges in THB, JPY, and other supported currencies
- Capture, reverse, or expire pending charges via dedicated action endpoints
- Issue full or partial refunds against any captured charge
- Save a customer's card as a token for future one-click charges
- Initiate transfers from the Omise balance to a registered recipient bank account
- Create payment sources for alternative methods such as Internet banking and TrueMoney
- Read the current account balance for reconciliation

## Use cases

### Card Payments for Thai E-Commerce

An e-commerce checkout collects card details client-side using vault.omise.co (public key) to mint a token, then calls POST /charges server-side with the token and amount in THB to capture the payment. Authorise-then-capture flows use POST `/charges/{id}/capture` so funds are only captured once goods ship.

Example prompt: Create a charge for 1500 THB on a token via POST /charges with capture=false, then call POST `/charges/{id}/capture` once the order ships.

### Refund and Reversal Workflow

When a customer disputes an order, POST `/charges/{id}/refunds` issues a full or partial refund against a captured charge, while POST `/charges/{id}/reverse` cancels an uncaptured authorisation cleanly. GET /refunds and GET `/charges/{id}/refunds/{refund_id}` support reconciliation against the merchant ledger.

Example prompt: POST a refund of 500 THB to `/charges/{id}/refunds` for a damaged-goods complaint and verify status by reading `/charges/{id}/refunds/{refund_id}.`

### Stored Card and Recurring Charges

POST /customers stores a customer record, then POST /charges with the customer ID re-uses the linked card for follow-up purchases - useful for subscription billing and one-click checkout. PATCH `/customers/{id}/cards/{card_id}` updates expiry data when banks reissue cards.

Example prompt: POST /customers with email and a token, then POST /charges with the customer ID to charge the saved card 299 THB for a monthly subscription.

### AI Agent Payment Operations

An AI agent integrated through Jentic can take a request like 'refund order #4521' and resolve it to the correct charge ID, call POST `/charges/{id}/refunds`, and surface the refund status - without ever holding the Omise secret key. Jentic encrypts and injects the credential at execution time.

Example prompt: Search Jentic for 'refund an omise charge', load POST `/charges/{id}/refunds`, look up the charge ID by order, and execute the refund.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/charges` | Create a charge |
| POST | `/charges/{id}/capture` | Capture an authorised charge |
| POST | `/charges/{id}/refunds` | Refund a charge |
| POST | `/customers` | Create a customer |
| POST | `/tokens` | Create a card token |
| POST | `/transfers` | Transfer balance to a recipient |

## Key resources

- **Charges** — Create, list, retrieve, update, capture, reverse, and expire charges; manage refunds attached to a charge.
- **Customers** — Create, retrieve, update, and destroy customers; manage their stored cards.
- **Tokens** — Mint single-use tokens client-side to keep raw card data off your servers.
- **Refunds** — Create, list, and retrieve refund records linked to charges.
- **Transfers and Recipients** — Move balance to recipient bank accounts and manage recipient records.
- **Sources** — Create payment sources for alternative methods (Internet banking, TrueMoney, etc.).

## Why Jentic

- **Setup:** Wiring Omise by hand means setting up HTTP Basic with two separate keys, routing charge and customer calls to api.omise.co while token creation goes to the vault.omise.co host, and handling the split yourself. Through Jentic you install once, import the Omise API from the API Directory, store the secret and public keys once, and your agent calls it with each request sent to the correct host.
- **Permission scoping:** Omise puts the charge id in the URL path (`/charges/{id}/capture`, `/charges/{id}/refunds`), so a rule can pin your agent to acting on a specific charge for follow-up operations. You choose the operations it may call, so it can create and capture charges without transfers or refunds unless you add those to the allowed set.
- **Credential handling:** Your Omise secret and public keys are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an omise charge' or 'refund an omise payment', and Jentic returns the matching Omise operation (POST /charges, POST `/charges/{id}/refunds`) with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Stripe API** — Global card and APM processor with broader country and method coverage.
- **Adyen Account Service** — Enterprise omnichannel payment platform with strong APAC presence.
- **Shopify Admin API** — E-commerce platform that uses Omise as a payment gateway.

## FAQ

### Why is there no official OpenAPI spec for Omise API?

Omise does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Omise API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Omise API use?

Omise uses HTTP Basic authentication. Server-side calls to api.omise.co use the secret key as the username (no password); tokenisation calls to vault.omise.co use the public key. Jentic stores both keys in the encrypted vault and selects the right one per endpoint.

### Can I issue partial refunds with the Omise API?

Yes. POST `/charges/{id}/refunds` accepts an amount smaller than the original charge to issue a partial refund. Multiple partial refunds are allowed up to the captured total.

### What are the rate limits for the Omise API?

Rate limits are not formally declared in the OpenAPI spec. In practice Omise applies per-account throttles; design clients to back off on HTTP 429 and avoid hammering /charges with the same idempotency context.

### How do I save a card for future one-click checkout through Jentic?

Search Jentic for 'save card on omise', and the SDK returns POST /customers and POST /charges. Create the customer with the token, then charge by customer ID for repeat purchases without re-tokenising.

### Does the Omise API include disputes and chargebacks?

The OpenAPI spec exposes refunds and reversals but not chargeback adjudication, which Omise handles operationally rather than through this API. Use refund endpoints for merchant-initiated returns.

### Can I limit what my agent is allowed to do with the Omise API?

Yes. Because you run Jentic One yourself, your own rules decide which Omise operations and credentials the agent may use, so you can allow it to create and capture charges (POST /charges, POST `/charges/{id}/capture`) while withholding refunds and transfers unless you add them to the allowed set. Since Omise puts the charge id in the URL path, such as `/charges/{id}/capture` and `/charges/{id}/refunds`, a rule can pin the agent to acting on a specific charge for follow-up operations. Your secret and public keys are stored encrypted by your own instance and injected only at execution time, so the agent scopes exactly what you permit and nothing more.