--- title: "Opn Payments Integration" description: "Opn Payments, formerly Omise, is a Thai payment gateway for cards, sources, and recurring charges. Agents create and capture charges, tokenize cards, issue refunds, manage customers and schedules, and track disputes with their evidence deadlines." url: https://flowrunner.ai/integrations/omise date_modified: 2026-09-04T14:51:36-07:00 --- # Opn Payments [Payments](https://flowrunner.ai/integrations/category/finance-accounting) Opn Payments, formerly Omise, is a Thai payment gateway for cards, sources, and recurring charges. Agents create and capture charges, tokenize cards, issue refunds, manage customers and schedules, and track disputes with their evidence deadlines. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 75 actions · Basic auth · available [Opn Payments website](https://omise.co/) · [Platform Documentation](https://docs.omise.co/) · Capability data verified 2026-08-25 1. A scheduled sweep polls List Disputes for anything awaiting a response 2. Agent reads each dispute with Get Dispute and notes the response deadline 3. List Charge Events reconstructs what actually happened on the disputed charge 4. Upload Dispute Document attaches the invoice, the delivery proof, and the terms page 5. List Dispute Documents confirms the evidence set is complete before anything is submitted 6. The deadline, the evidence list, and the fee at stake post to the finance channel 7. The operations owner chooses between Accept Dispute and Close Dispute ## What This Integration Enables Opn Payments, formerly Omise, is a Southeast Asian gateway, and the shape of its API tells you what it thinks the hard part is. Charges and refunds get the coverage you would expect. What is unusual is the dispute surface: opening, reading, defending, conceding, and closing a chargeback, with a separate document store for the evidence and a deadline sitting on the record itself. Very few payment connectors expose that as a workflow rather than as a dashboard. The other thing worth noticing is the honesty of its read side. Get Capability answers which payment methods your specific account may actually use, which is a narrower set than the platform publishes. List Events is the account's own log of every state change, whether or not your listener received the delivery, which makes it the recovery mechanism after an outage. FlowRunner agents take payments, run schedules, pay out to verified recipients, and work disputes on their clock. The decision that costs money, at the moment it costs money, is where [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) comes in. ### Without FlowRunner **Disputes discovered by accident**: Nobody is told a dispute exists, so the response window closes before anyone opens it **Evidence assembled under pressure**: Documents are hunted down on the last day from three different systems **Authorizations left hanging**: A canceled order leaves a hold on the customer's card until the issuer expires it ### With FlowRunner **Disputes surfaced with their clock**: The pending set is polled and each one arrives with its deadline attached **Evidence gathered as it lands**: The invoice, the delivery record, and the event history are attached while the case is opened **Holds released deliberately**: A canceled order reverses its authorization rather than waiting for the issuer to time out ## Use Case Scenarios ### Local payment methods without hard-coded assumptions A Thai customer reaches checkout. Rather than offering a list copied from documentation, the agent calls Get Capability and reads which methods this account is actually enabled for, since the set differs by country and by contract. It creates the matching source with Create Source, then hands that source to Create Charge with an exactly matching amount and currency. Get Source tells the flow what has to happen next: a redirect sends the customer off site, an offline flow gives them a code or a QR to pay later, and an app redirect opens a wallet. An abandoned basket is closed cleanly with Expire Charge so the order can be attempted again. ### Subscription billing that sees a decline coming Recurring charges run on schedules. Each week the agent reads List Schedule Occurrences, which records every run as successful, failed, or skipped with a message, so a subscriber whose card is declining shows up before they complain. For each failing subscription it reads List Customer Cards and checks the stored expiry, then messages the customer with a link to update their card. Before any cleanup job deletes a card or a customer, it calls List Customer Schedules first, because deleting underneath a schedule fails silently at its next occurrence rather than raising an error anyone would see. ### Webhooks that are verified rather than believed Opn Payments does not sign its deliveries. So the agent takes only the event identifier from the posted body and calls Get Event to fetch the real thing, which turns an unauthenticated request into a trusted one. If the listener was down, List Events replays the account's own log to catch up, since there is no delivery retry API to lean on. Reconciled events feed a ledger view built from List Transactions, which is not the charge list: a charge, its fee, its refund, and a transfer out each produce their own entry, and that is what makes the balance reconcile against [Xero](https://flowrunner.ai/integrations/xero). ## Human-in-Loop Highlight A dispute puts two irreversible operations in front of an agent and gives it a deadline to choose between them. Accept Dispute concedes: the money goes back to the cardholder, the case ends, and nothing undoes it. Close Dispute defends: it submits what you have and stops Update Dispute and Upload Dispute Document from being useful, so evidence you find afterwards is worth nothing. Sitting on the fence is also a decision, because a dispute left unanswered past its closing date is decided against you automatically. The agent does the work either path needs: it pulls the charge's full event history, attaches the invoice and the delivery proof, drafts the written response, and confirms the evidence set is complete. Then it stops. "Dispute on charge chrg\_5tp for 4,900 THB, evidence due in three days. Three documents attached. Contesting costs a fee whether or not we win. Defend or concede?" The operations owner answers, and the call that cannot be taken back was made by a person who could weigh the fee against the odds. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 75 actions ### Tokens and Cards 2 - **Create Token** Turns raw card details into a single-use token. This is the one operation that uses the public key, on a separate host, so card data never touches the secret key. A token is spent once it has made a charge or been attached to a customer, and in production the browser and mobile SDKs should tokenize instead, which keeps your systems out of card-data scope. - **Get Token** Returns a token and the card behind it. The used flag says whether the token has been spent and the charge status says what happened to the charge it made, which distinguishes never used from used and declined. ### Charges 11 - **Create Charge** Takes a payment. The amount is in the smallest currency unit. There are three mutually exclusive ways to pay: a token, a stored card together with its customer, or a source for one of the local methods. Authorizing without taking money must be followed by a capture, and a zero amount is the platform's own card-validation pattern. - **Get Charge** Returns one charge in full. Read the status rather than the paid flag alone, since a pending charge carrying an authorization URI is waiting for the customer to finish a 3DS or off-site step, and the failure code says why a decline happened. - **List Charges** Lists charges over a date range, paged by limit and offset with a maximum of one hundred per page. The default order is oldest first. - **Update Charge** Changes a charge's description or metadata after the fact. It cannot change the amount or the card, so this is for attaching an order number you did not have at charge time. - **Capture Charge** Collects money that was authorized but not taken. This is the step people forget, since an uncaptured authorization eventually lapses and the sale is never collected. With a pre-authorization you may capture less than was authorized, which is what a hotel or a fuel pump needs. - **Reverse Charge** Releases an authorization without collecting it. This is what a canceled order needs, because otherwise the hold sits against the customer's credit limit until the issuer expires it. It works only on an uncaptured charge. - **Expire Charge** Ends a charge that is waiting for the customer. Off-site methods leave a charge pending until the customer acts or it times out, so expiring it deliberately is how an abandoned basket is closed cleanly. - **Mark Charge As Paid** Records that an offline payment method was settled. This is a bookkeeping operation, not a payment: it moves no money and exists for methods the platform cannot confirm itself. - **Mark Charge As Failed** Records that an offline payment never arrived, the counterpart of marking a charge paid, for closing off a charge whose customer never paid. - **List Charge Events** Returns every event recorded for one charge: created, authorized, captured, reversed, refunded, disputed, each with its timestamp. This is the audit trail for a disputed payment, and it survives even when your own listener missed the deliveries. - **List Link Charges** Returns the charges made through one payment link. A multi-use link can be paid many times, so this is how you see everyone who used it. ### Sources 2 - **Create Source** Creates a source for one of the local payment methods. A source is not a payment: it is an intent that must then be handed to a charge, and its amount and currency must match exactly. - **Get Source** Returns one source. Its flow field says how the customer completes it, which decides what your own interface must do next. ### Refunds 4 - **Create Refund** Gives money back on a captured charge. Leave the amount empty for a full refund or supply less for a partial one, and several partial refunds can be made until the charge is exhausted. An uncaptured authorization needs a reversal instead. - **Get Refund** Returns one refund of a charge. - **List Charge Refunds** Returns every refund made against one charge, which is how the several partial refunds of a partly-returned order are seen together. - **List Refunds** Returns every refund on the account, across all charges, the accounting view of money going back out. ### Customers and Stored Cards 9 - **Create Customer** Creates a customer, optionally attaching a card at the same time. Passing a token here is how a card is stored: the token is spent turning into a permanent card on the customer, which can then be charged again. - **Get Customer** Returns one customer with their cards. The default card is the one a charge uses when you name the customer and no card. - **List Customers** Returns your customers, up to one hundred per page. - **Update Customer** Changes a customer's details or adds a card. Passing a new token adds a card and makes it the default, which is how a payment method update is implemented, and the old card stays attached unless it is deleted. - **Delete Customer** Removes a customer and their stored cards. Their past charges remain, so this deletes the ability to charge them again rather than the record that you did. - **List Customer Cards** Returns the cards stored on a customer, with brand, last four digits, and expiry. Reading the expiry is how a flow warns a subscriber before their card lapses. - **Get Customer Card** Returns one stored card. The security code check says whether the CVV was verified when the card was stored, which some acquirers weigh when approving a later charge. - **Update Customer Card** Changes a stored card's billing details or expiry. The card number cannot be changed, so this is for a reissued card with the same number and a later expiry, or for correcting a billing address that is failing address checks. - **Delete Customer Card** Removes a stored card from a customer. Check what depends on it first, since deleting the card a schedule charges makes that schedule fail silently at its next occurrence. ### Schedules 10 - **Create Schedule** Sets up a recurring charge or transfer. One route covers both: supply a charge object for money in or a transfer object for money out. The interval is an every-and-period pair narrowed further by an on object, and both a start and an end date are required. - **Get Schedule** Returns one schedule with its status and its next occurrences, which is what a question about the next billing date needs. - **List Schedules** Returns your schedules, charge and transfer alike. - **Delete Schedule** Stops a schedule. This is how a subscription is canceled, since there is no pause on a single schedule through the API. - **List Schedule Occurrences** Returns each time a schedule has run and what happened. This is the dunning view: an occurrence records successful, failed, or skipped with a message, so a declining card shows up before the customer complains. - **Get Occurrence** Returns one run of a schedule, including the charge or transfer it produced and, when it failed, the message saying why. - **List Customer Schedules** Returns the charge schedules billing one customer. Run this before deleting a card or a customer, since it is the only way to see what recurring billing depends on them. - **List Recipient Schedules** Returns the transfer schedules paying one recipient, the payout side of the customer view, with the same warning before deleting a recipient. - **List Charge Schedules** Returns every charge schedule on the account, the subscriptions view, without the transfer schedules mixed in. - **List Transfer Schedules** Returns every transfer schedule on the account, the recurring payouts, without the charge schedules mixed in. ### Transfers and Recipients 13 - **Create Transfer** Moves money from your balance to a bank account. The amount defaults to your entire transferable balance if left empty, so read the balance first. The recipient defaults to the account's own default recipient, and an idempotency key is what stops a retried flow paying twice. - **Get Transfer** Returns one transfer. Sent and paid are different things: sent means the platform released it, paid means the receiving bank has it. - **List Transfers** Returns your transfers, the payout history, and the other half of a reconciliation against your bank statement. - **Update Transfer** Changes an unsent transfer's amount or metadata. It works only while the transfer has not been sent. - **Delete Transfer** Cancels an unsent transfer. Only possible before it is sent. - **Mark Transfer As Sent** Records that a transfer has been released. In practice this is a test-mode operation for exercising a payout path without a real bank, since a live account moves transfers through these states itself. - **Mark Transfer As Paid** Records that a transfer reached the receiving bank, the second half of the test-mode payout simulation. - **Create Recipient** Registers a bank account to pay money to. A new recipient is not usable until verified, and the account holder name must match what the bank holds. - **Get Recipient** Returns one recipient. Verified and active are both required before a transfer will reach them, and an unverified or inactive recipient is the usual reason a payout fails for no obvious reason. - **List Recipients** Returns the bank accounts you can pay to. - **Update Recipient** Changes a recipient's details or bank account. Changing the bank account resets verification, so a supplier who changed banks stops being payable until that completes. - **Verify Recipient** Marks a recipient as verified. On a live account the platform verifies against the bank itself, so this exists to exercise a payout flow end to end without one. - **Delete Recipient** Removes a recipient. Check the transfer schedules paying them first, since one will start failing at its next occurrence. ### Disputes 10 - **Create Dispute** Opens a dispute against a charge. Normally a cardholder's bank raises one and it appears without your involvement, so this route is for the cases where you raise it yourself. - **Get Dispute** Returns one dispute. Its closing date is a deadline rather than a fact while the dispute is open: it is the date by which your evidence must be in, and missing it loses the dispute by default. - **List Disputes** Returns disputes. Poll this, because a dispute arrives with a response deadline and nothing but the API tells you. The pending status is the set awaiting your evidence and the one worth alerting on. - **Update Dispute** Attaches your written response to a dispute. Together with uploaded documents it is what the issuing bank weighs, and a dispute left unanswered until its closing date is decided against you. - **Accept Dispute** Concedes a dispute. The money goes back to the cardholder and the case ends. It is irreversible, and it is the right call when the customer is plainly correct. - **Close Dispute** Submits your defense and closes the dispute for review. Do it only once the evidence is complete, since updating the response and uploading documents both stop being useful afterwards. - **Upload Dispute Document** Attaches a file to a dispute: an invoice, a delivery receipt, a signed terms page. The documents plus the written message are the whole of your case, and the bank sees only what you attach before the dispute is closed. - **List Dispute Documents** Returns the evidence attached to a dispute, a check that everything you meant to send is actually there before closing. - **Get Dispute Document** Returns one attached document with its download URI. - **Delete Dispute Document** Removes a piece of evidence from a dispute, for a file uploaded by mistake, before the dispute is closed. ### Account, Balance, and Ledger 11 - **Get Account** Returns the account this key belongs to, including its API version and the currencies it supports. The cheapest way to confirm a key works and which account and mode it points at. - **Update Account** Changes account settings such as the default webhook URIs and the chain-enabled flag. - **List API Versions** Returns the API versions the platform offers. Responses are versioned by date and the version your account is on decides the shape of everything returned, so pin one on the connection rather than letting an upgrade change a running flow's data. - **Update API Version** Moves the account onto a different API version. This changes response shapes for every integration on the account, not just one flow, so setting the version on the connection is nearly always safer. - **Get Balance** Returns your balance. Three figures that are not the same: the total is everything held, the transferable figure is what may be paid out now, and the reserve is what the platform holds back against future refunds and disputes. - **Get Capability** Returns exactly which payment methods, currencies, installment terms, and banks your account may use. This is the only honest answer to which source types you can create, since any given merchant is enabled for a handful of the published methods. - **Get Forex** Returns the exchange rate from your account's base currency into another. Used to show a customer what a multi-currency charge will actually cost them, since the platform charges at its own rate. - **List Transactions** Returns your ledger entries, every credit and debit that moved your balance. This is the accounting view rather than the charge list, and it is what makes the balance reconcile. - **Get Transaction** Returns one ledger entry with the object that produced it. - **List Receipts** Returns the platform's own tax receipts to you, the invoices for its fees, rather than receipts you give customers. This is the input for your own expense accounting. - **Get Receipt** Returns one fee receipt, with its tax breakdown. ### Events and Search 3 - **List Events** Returns the account's event log, every state change recorded, whether or not your listener received it. This is the webhook recovery mechanism, since there is no delivery retry API. - **Get Event** Returns one event with the object it carried. Use it to verify a webhook: take only the event identifier from the posted body and fetch the real thing here, which turns an unauthenticated request into a trusted one. - **Search** Searches across charges, customers, disputes, recipients, refunds, transfers, and links. It pages differently from the other lists here and accepts the ranges and keywords the platform's own dashboard uses. ## Frequently Asked Questions ### What can FlowRunner do with Opn Payments? FlowRunner agents can run Create Token, Get Token, and Create Charge in Opn Payments, plus 72 more actions. ### Does connecting Opn Payments to FlowRunner require OAuth? No. Opn Payments connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can Opn Payments trigger a FlowRunner workflow automatically? Opn Payments doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Opn Payments?** This integration exposes Opn Payments to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/omise. Site index: https://flowrunner.ai/llms.txt