How to show Stripe MRR on the Jira ticket that tracks the request
There's no setting for this because Jira and Stripe don't know about each other. The fix is a custom Number field on the issue, formatted as currency, that carries the requesting account's monthly recurring revenue alongside the summary and the description. Populate it once by hand for a single ticket, or wire a Jira Automation rule to pull it from Stripe automatically whenever a ticket is created or a customer's plan changes. Either way, the number lives on the ticket, not in a tab someone has to remember to open.
A Jira issue by default carries a Reporter, a summary, and a description. It has no concept of an account's plan or spend, because that information lives in Stripe, and the two products have no reason to talk unless you connect them yourself. Once you add the field, though, an engineer scanning the backlog sees "$4,200/mo" sitting next to "add bulk CSV export" instead of a bare feature name that reads identically whether it came from a free trial or your biggest account.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhy Jira doesn't already do this
Jira's built-in fields describe the ticket, not the account behind it: Reporter, Priority, Labels, Components. None of them are billing-aware, and there's no first-party Stripe field anywhere in Jira Cloud's field picker. That's not an oversight specific to Stripe. Jira is a work tracker; it has no billing system of its own to draw from, so any revenue number on an issue has to arrive from outside.
The mechanism Jira does give you for adding one is the custom field. Number Field is one of Jira's built-in custom field types, and it ships with a Currency display format specifically so a value like MRR renders as "$4,200.00" instead of a bare integer. Add it to your Story and Bug issue types (call it Requester MRR), and it behaves like any other field: sortable in a board, filterable in JQL, visible in the issue view without opening a second tab.
The manual version: one field, one lookup
For a team filing a handful of customer-linked tickets a week, this doesn't need automation:
- Create the field. In project settings, add a custom field of type Number, format Currency, called
Requester MRR. Add it to the relevant issue types. - Look up the account in Stripe. Stripe's Customer Search API matches on email exactly (
customers/search?query=email:'name@company.com'), or run the same search in the Dashboard's search bar. Expand the result into its active subscription. - Read the price, not the balance. The Customer object carries a
balanceandmetadata, nothing that states plan value directly. The subscription's price object has aunit_amountin cents (so $49/month is stored as4900) and arecurring.interval. Divide by 100, then annualize or leave monthly depending on which number you want next to the ticket. - Type it into the field. One value, done, until the account's plan changes and someone remembers to update it.
That's genuinely enough for low volume. It stops being enough the moment "someone remembers to update it" becomes the load-bearing part of the process, which is the same failure mode as any manually maintained number.
Automating the lookup with Jira Automation
Jira Automation can close the loop itself. Atlassian's own documentation confirms the relevant action: a rule's Send web request step "sends an outgoing web request to notify another system when a flow is run," and you can "set this action to return response data that can then be used in a subsequent action." That's the whole mechanism:
- Trigger: issue created, or a scheduled trigger that re-checks open issues nightly.
- Send web request: a GET to Stripe's Customer Search endpoint, with the ticket's requester email (pulled from a custom field or the description) as the query parameter, and your Stripe secret key in the Authorization header.
- Edit issue fields: write the response's subscription amount, divided by 100, and divided by 12 for annual plans, into
Requester MRRusing the automation rule's smart values.
The same rule pattern can run on a schedule instead of only at creation, so a ticket's MRR field reflects an upgrade or downgrade instead of staying frozen at whatever the account was paying when the ticket was filed. What it can't do is match the right customer automatically when the requester's email in Jira doesn't match the billing contact's email in Stripe, a support engineer filing on a customer's behalf, a shared inbox address, a personal email versus a work one. That mismatch is a real gap, and it's the same one that shows up in the manual version.
What changed on Loopwave Analytics's board
Loopwave Analytics sells uptime and API-latency monitoring, billed monthly through Stripe across Starter, Growth, and Enterprise plans. Its engineering backlog sat in Jira, and for most of last year a webhook request from a two-week trial looked identical to one from a six-figure account: same fields, same layout, no dollar figure anywhere on either ticket.
The gap showed up during a sprint planning session, when engineering manager Imogen Voss noticed the team spending equal time on two open stories asking for the same kind of webhook support, with nothing on either ticket to say which account actually needed it more. She added Requester MRR as a Currency-formatted Number field on the Story issue type, then built the Jira Automation rule described above: on issue creation, look up the requester's email in Stripe, and write the resulting monthly amount into the field.
One of the two tickets had come in from Rafael Duarte at Trestlebridge Logistics, an Enterprise customer, asking for a webhook on latency spikes over 500ms so his team could stop polling Loopwave's status endpoint every 30 seconds by hand. Before the rule ran, that request sat in the backlog with no way to tell it apart from the similar ask filed by a trial account still deciding whether to convert. After, the issue view read Requester MRR: $2,850.00 next to the other request, sitting at $0. Imogen didn't have to ask which one to prioritize in the next planning session. The field settled it.
Where the automation stops holding up
The rule Imogen built works cleanly for as long as three things stay true:
- The requester's email matches Stripe exactly. A ticket filed by a support engineer on a customer's behalf, or from a shared inbox, breaks the match silently, and the field either fills with the wrong account's MRR or stays empty.
- One person owns the automation rule. Jira Automation rules live in project settings; if the person who built it leaves or the API key it uses expires, the field quietly stops updating and nobody notices until the numbers look stale.
- The account has exactly one active subscription. Multi-product accounts, seat add-ons, or a recent plan change mid-cycle all complicate the "just read
unit_amount" math, and the rule either needs to sum multiple line items or it under-reports.
None of these breaks the field outright. They lower its accuracy quietly, the same way a spreadsheet drifts, and a wrong number on a ticket is worse than no number, because a wrong number looks authoritative.
There's no fixed ticket count where this tips over, but a fair signal is the moment a bespoke automation rule and a standing API key are the only things keeping one field honest. Past that point, teams tend to look for something that keeps Stripe and Jira connected as a matter of course instead of patching another rule. That's the category we build in. Modem connects to Stripe once you authorize it, matches Stripe customers to the people and companies it already tracks from Slack, support, and email, and carries plan and revenue context onto every request tied to that account. Because that context lives on the account relationship rather than in one field populated by one rule, it isn't thrown off the way a single unit_amount read can be when an account is running more than one active subscription. Modem's Jira integration then attaches that same context to the ticket the request becomes, so the MRR figure updates when the account's plan changes instead of freezing at whatever it was when the automation last ran, and it doesn't depend on one email match per ticket. Modem is our product, so read that recommendation with the obvious bias attached; the underlying revenue-matching problem is covered in more depth in connecting Stripe revenue to customer feedback, and the companion question of who asked (rather than how much they pay) is covered in how to see who actually asked for a Jira epic or story.
Below that volume, the custom field plus a single automation rule costs nothing extra and does the job.
Set it up this afternoon
Add a Currency-formatted Number field called Requester MRR to your Story and Bug issue types. Populate it by hand for your five oldest open customer-linked tickets using Stripe's search bar. If that changes even one prioritization conversation, that's the case for building the automation rule next.
