Instamojo

Instamojo is an Indian payments platform for collecting money through payment requests. Agents create payment requests, raise orders from them, read payment details, and issue refunds through the resolution center.

6 actions OAuth available

Instamojo website Platform Documentation Capability data verified 2026-08-25

An invoice is approved for collection in the billing system

Agent reads the customer, the amount in rupees, and the invoice reference

Agent confirms the amount sits inside Instamojo's bounded minimum and maximum

Agent looks for an existing link on this invoice, because none can be withdrawn later

The request is assembled with repeated payments switched off and the reference attached

The proposed amount and link settings post to the collections channel

The collections owner approves, and Create Payment Request issues the link

What This Integration Enables

Instamojo is built for sellers who want to collect money in India without building a checkout. The whole product is a link. You name an amount, Instamojo hosts the page, and the buyer pays through whichever instrument they prefer. FlowRunner agents work at exactly that grain: create the request, hand back the URL, read the payment that comes in, and file a refund when one is owed.

The small surface is the point, and it shapes how an agent should behave here. Six operations mean there is no update route, no delete route, and no way to close a request after it exists. So the interesting engineering is not in the calls. It is in what the agent does before the call, which is where FlowRunner's human-in-the-loop discipline belongs on this connector. Agents assemble and verify; a person signs off on the one write that cannot be taken back.

Without FlowRunner

Links live outside the ledger A payment URL gets pasted into a chat thread and nothing connects it back to the invoice

Redirects treated as receipts The browser return page is taken as proof of payment, and reconciliation finds the gap later

Refunds handled by conversation A refund starts as an email to support and is tracked in someone's inbox until it settles

With FlowRunner

Every link carries its reference The request is created with the invoice reference attached and read back against it

Payment confirmed at the source Get Payment is the answer of record, and the redirect is treated as a claim

Refunds tracked as open cases A refund is filed with its reason, given a case identifier, and followed until it closes

Use Case Scenarios

Collections that stay attached to the invoice

An invoice reaches its due date in QuickBooks Online or Zoho Books. The agent reads the balance, converts it to the figure Instamojo expects, and confirms it sits inside the platform's bounded minimum and maximum. It then calls Create Payment Request with the invoice number as the reference and a per-request webhook pointed at this flow rather than at a shared account endpoint. The returned URL goes back onto the invoice record and out to the customer over WhatsApp or email. Nothing about the link is guessed later, because the reference traveled with it.
Confirming money actually arrived

A buyer finishes paying and the browser lands on the return URL. That redirect is a claim made by a browser, and the agent treats it as one. It calls Get Payment Request to read the payments recorded against the link, then Get Payment on each one to read the platform's own answer: whether the status is Credit or Failed, which instrument was used, and who paid. Only a Credit result marks the invoice settled and posts a confirmation into Slack. A Failed result routes the customer a fresh request instead of a receipt.
A refund that is followed rather than fired and forgotten

A support conversation ends in an agreed refund. The agent calls Create Refund with the reason and the written explanation Instamojo requires, and supplies a distinct transaction identifier so a retried call cannot open a second case for the same money. Instamojo files the refund as a resolution center case rather than an instant reversal, so the agent polls Get Refund until the case closes and posts each state change into the customer's Zendesk ticket. The customer sees the refund move rather than waiting in silence.

Human-in-Loop Highlight

Look at what this connector cannot do. There is no update operation, no delete operation, and no revoke. Once Create Payment Request returns a URL, that URL exists for good, and Instamojo turns on repeated payments by default, so the same link can be paid again by anyone who still has it. A one customer invoice sent with that default left on is a link that can collect the same money twice. So the agent stops before the write, not after it: "Invoice INV-4471 for Sharma Traders, 18,400 rupees, single use. Repeated payments will be switched off. Confirm the amount and the setting, because this link cannot be edited, closed, or deleted once it exists." The collections owner answers in Slack, the agent issues the link, and the one write with no undo was a decision a person made.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

6 actions

Payment Requests

Create Payment Request Issues a payment request and returns the hosted URL to send the customer. This is the platform's main way of taking money, with no checkout to build, and the amount must sit inside Instamojo's published minimum and maximum in rupees. The repeated payments setting decides whether the link collects once or many times, and the webhook is per request, so a flow can route this one payment's notification to its own endpoint.
Get Payment Request Reads one payment request along with the payments made against it. With repeated payments left on there can be several, which is why the response carries a payments array rather than a single payment.
Create Order From Payment Request Turns a payment request into an order for Instamojo's mobile SDKs. Used when an Android or iOS app presents the payment natively; a web flow does not need it, because the request URL is already a complete checkout.

Payments

Get Payment Reads one payment: what was paid, by whom, through which instrument, and its final status. This is the operation that verifies a payment, because a redirect or a webhook is a claim and this is the platform's own answer.

Refunds

Create Refund Refunds a payment in whole or in part. Instamojo models a refund as a resolution center case rather than a payment operation, which is why a reason and a written body are both required. From the second refund onward on the same payment, a distinct transaction identifier is required so a replayed call cannot open a duplicate case.
Get Refund Reads one refund by its case identifier. A refund has a status of its own and can sit pending, because it is a case being worked rather than an instant reversal.

Frequently Asked Questions

What can FlowRunner do with Instamojo?

FlowRunner agents can run Create Payment Request, Get Payment Request, and Create Order From Payment Request in Instamojo, plus 3 more actions.

Does connecting Instamojo to FlowRunner require OAuth?

Yes. Instamojo connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.

Can Instamojo trigger a FlowRunner workflow automatically?

Instamojo doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Instamojo

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us