Use cases / When someone needs an answer
Stripe says paid. The app says free.
At month-end, Stripe and the product disagree on who is paying, finance can see two totals but not which accounts are wrong, and a paying customer is already locked out.
Jigward builds a small Application that compares both systems account by account, separates differences that exist by design from real errors, and files the failing payment webhook as a Jira bug for the team that owns it. Every account change and the fix stay with people.
The film
Chapters
Read the narration
0:00 Stripe and the app disagree at month-end
Month-end close. Stripe and the app disagree, Finance cannot identify which accounts are wrong, and a paying customer is already locked out. I'm Jigward. Finance hands this over in a private conversation, and nothing begins until she confirms. My access to both systems is read-only.
0:23 A reconciliation Application that only reads
An admin connected Stripe and the admin API, read only. Each subscription names its workspace. That's my match key. A script that runs once gets forgotten, so I'm building a small tool instead. Both systems are fetched page by page, then compared.
0:45 Eighteen accounts, three kinds
Eighteen accounts differ. Nine are trials and coupons, different by design. But seven paid and sit on Free, and two canceled but kept access.
0:57 Why paying customers are stuck on Free
Why are payers stuck on Free? For three of them, the logs show payment events failing right now, while Stripe keeps retrying. Here's the cause: the code identifies the workspace only through the Stripe customer. So when a payer's customer record changes, the upgrade silently fails.
1:21 Filed for the billing team
That's a real bug, not a counting difference. As Finance asked, it goes to the billing queue with the evidence, instead of interrupting an engineer.
1:33 A quiet daily check, and people decide
From tomorrow, I'll run this comparison every morning. If nothing new turns up, nobody hears from me. Nothing changed in Stripe or the app. From here, people decide: support restores the payers, Finance picks grace or downgrade, and Maya's team owns the fix.
What changes
Today. At month-end, finance sees two totals that do not match, and support hears from a customer who paid and is still locked out. The usual answer is to interrupt an engineer for a one-off script that joins the two systems once and is never run again. Billing dashboards and revenue reports show a net gap, which hides errors in both directions. Part of it is trials and coupons the two systems count differently by design, and nothing separates those from the real errors.
-
Before: A net gap of 14 between two totals.
With Jigward: Eighteen accounts by name, in three groups, each with what Stripe and the product say.
-
Before: A one-off script an engineer writes mid-sprint and nobody runs again.
With Jigward: A small Application that keeps the comparison, and a daily Duty that reruns it and speaks only when new drift appears.
-
Before: A message to whichever engineer answers first.
With Jigward: A Jira bug for the owning team, with the log line, the code line and the number of payers affected.
What Jigward does
Stripe shows 412 paid subscriptions and our admin panel shows 398 paid accounts. Which accounts are wrong? If something is broken, file it in BILL for the billing team instead of pinging an engineer.
Connected beforehand
- The finance lead's Slack account is linked, so their direct messages reach Jigward.
- Stripe and the company's admin API are custom integrations. Jigward worked the admin API out from documentation the team provided, and an admin applied only the reading operations of both.
- An AWS account is connected, so Jigward can read the production log groups an admin allowed.
- The billing repository is connected through GitHub, and the billing team's Jira project is named with the Context.
-
Finds the match key
Jigward checks what each integration can read and samples one Stripe subscription. Each subscription names the product account it belongs to, which is the key to compare on.
-
Builds a comparison, not a script
It builds a team Application, "Billing drift", that fetches both systems page by page and compares them account by account. The first run reads all 1,268 subscriptions and 2,315 product accounts, and 18 accounts differ.
-
Sorts the differences
Nine are trials and 100%-off coupons that the two systems count differently by design. Seven paid but sit on Free, and two canceled but kept access.
-
Traces the payers stuck on Free
A search of the last 24 hours of webhook logs finds payment events failing for three of the seven, while Stripe keeps retrying. The handler code looks the account up only through the Stripe customer, so when a payer's customer record changes, the upgrade fails.
-
Files it for the owning team
As the finance lead asked, Jigward files a Jira bug in the billing team's project with the log line, the code line and the number of affected payers, instead of messaging an engineer.
-
Sets a quiet daily check
A Duty reruns the comparison every morning and reports only when new drift appears. When nothing is new, nobody hears from it.
Jigward in this case
-
Slack
The request arrives as a direct message to Jigward. Nothing starts until the finance lead clicks Create on the Task card, and the summary comes back there.
-
Custom API
Stripe and the admin API are called through the reading operations an admin applied, so nothing is written to either.
-
Applications
A team Application fetches both systems, stores the 18 differing accounts and shows each with its next step.
-
AWS CloudWatch Logs
A log search over 24 hours of webhook logs finds the failing payment events for three payers.
-
Jira
The bug goes to the billing team's project with the evidence, linked to the Task.
-
Duties
A daily Duty reruns the comparison and stays silent unless new drift appears.
What comes back, and what stays with the team
What comes back
- The "Billing drift" Application Every differing account, what Stripe and the product each say, and the next step for each.
- Jira A bug for the billing team with the log line, the code line and the number of affected payers.
- The direct message in Slack The three groups, the cause confirmed for three payers and only likely for the other four, what was not checked, and links to the Application, the Jira issue and the Task.
What the team decides
- Restoring access for the seven paying customers, which support does.
- Grace or downgrade for the two canceled accounts, which the finance lead chooses.
- How and when to fix the handler, and whether to replay the failed events. Jigward writes nothing to Stripe or the product.
What Jigward did not check
- Whether the other four payers failed the same way. Their events are older than the 24-hour log search.
- Refunds, plan prices and amounts.
- Why the two canceled accounts kept access.
- Whether the handler's other paths fail too.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.