DEV Community: Veristria

What a lost dispute actually costs a Connect platform

Veristria — Fri, 21 Aug 2026 13:40:43 +0000

Refunds get the attention. Disputes are worse, and the reason is structural rather than a matter of degree.

On a refund you at least have a parameter. reverse_transfer: true exists, you can pass it, and if you forget there is a boolean to point at afterwards. On a dispute there is no such parameter, because there is no such option.

What Stripe does when you lose

Stripe debits the platform for the disputed amount plus the dispute fee. That is it. That is the whole automatic behaviour.

The connected account that received the original transfer is not touched. Not reduced, not notified, not flagged. From that seller's perspective nothing happened at all — the money arrived weeks ago and is still theirs.

So the platform's position after losing a dispute on a destination charge is:

- disputed amount   (debited from platform balance)
- dispute fee       (debited from platform balance, typically ~15 USD)
+ nothing            (the transfer is untouched)

The seller keeps the funds. You paid the customer back and paid a fee for the privilege.

Why this is not symmetrical with refunds

A refund is initiated by you, so Stripe can offer a parameter at the moment of initiation. A dispute is initiated by the cardholder's bank, days or weeks after the charge, through a process you are not in. There is no call of yours to attach a flag to.

The reversal, if you want one, has to be a separate action you take afterwards:

// on charge.dispute.closed with status 'lost'
await stripe.transfers.createReversal(transferId, {
  amount: disputedAmount,       // not necessarily the full transfer
  description: `dispute ${disputeId}`,
});

Nothing calls that for you. If your webhook handler for charge.dispute.closed only writes a row and updates a status, the clawback never happens.

Three things that make this accumulate quietly

The timing hides it. A dispute closes 30 to 90 days after the charge. By then the transfer is in a different payout, a different month, and usually a different reconciliation report. The debit and the un-reversed transfer are never adjacent in any view you look at.

The connected balance may not cover it. Even when you do reverse, the seller may have already paid out. The reversal leaves the account negative, which surfaces later as a failed payout — a third event, in a fourth place, with no obvious link back to a dispute.

Winning still costs. The dispute fee is generally not returned on a win in most regions. A platform with a good win rate still bleeds fees, and those fees are charged to the platform rather than to the seller whose transaction caused them.

The reconciliation query

The question is the same shape as the refund one, and it is worth running over full history rather than a recent window, because the whole failure mode is that it is old by the time it matters:

SELECT d.id                AS dispute_id,
       d.charge_id,
       d.amount            AS debited,
       d.fee               AS dispute_fee,
       COALESCE(r.amount, 0) AS reversed,
       d.amount - COALESCE(r.amount, 0) AS unrecovered
  FROM disputes d
  LEFT JOIN transfer_reversals r ON r.charge_id = d.charge_id
 WHERE d.status = 'lost'
   AND d.amount > COALESCE(r.amount, 0)
 ORDER BY unrecovered DESC;

The policy question underneath the technical one

Whether to claw back is genuinely a business decision, and reasonable platforms answer it differently. A marketplace with sellers who have no control over fraud may absorb disputes deliberately. A platform whose sellers do control fraud usually should not.

What is not a decision is doing it by accident. If you have never reversed a transfer on a lost dispute, you have chosen to absorb every one of them — you just did not know that was the choice you were making. Run the query and find out which platform you are.

The Stripe Connect refund that only costs the platform

Veristria — Fri, 21 Aug 2026 13:39:36 +0000

There is a class of bug in Stripe Connect that never throws, never logs, and never fails a webhook. The refund succeeds. The customer is made whole. The money comes out of your balance and stays with the seller.

It is worth understanding precisely, because the fix is one boolean and the detection is one join.

What a destination charge actually is

On a destination charge, one API call does two things: it charges the customer, and it creates a transfer moving funds to the connected account. Two objects, one call.

A refund, by default, only undoes the first one.

// the customer gets their money back. the transfer is untouched.
await stripe.refunds.create({ charge: 'ch_123' });

// the transfer is reversed too
await stripe.refunds.create({
  charge: 'ch_123',
  reverse_transfer: true,
});

reverse_transfer defaults to false. That default is defensible — sometimes the platform genuinely wants to absorb a refund rather than claw it back from a seller who already shipped. What makes it a footgun is that choosing wrongly produces no signal at all.

The second flag, which is not the same flag

refund_application_fee is independent. Reversing the transfer does not refund your platform fee, and refunding the fee does not reverse the transfer.

That means a refund can be wrong in either direction on its own:

transfer reversed, fee kept -> you kept a fee on revenue that no longer exists
fee refunded, transfer not reversed -> you paid the customer and gave up the fee

Three details that bite during reconciliation

Partial refunds do not partially reverse unless you ask. A partial refund with reverse_transfer: true reverses the corresponding fraction. A partial refund without it reverses nothing at all — not a smaller amount, nothing.

A negative connected balance does not block the refund. The reversal is attempted and the account can be left negative. You find out later, as a failed payout, in a different part of the system, with no obvious link back.

Disputes behave differently again. On a lost dispute, Stripe debits the platform in full. The connected account that received the transfer is untouched unless you reverse it yourself. There is no reverse_transfer on a dispute.

The query that finds them

The reconciliation question is not "did the refund succeed". It is: for every charge.refunded, is there a matching transfer.reversal of the expected amount?

Working from the events you already receive:

SELECT r.charge_id,
       r.amount                      AS refunded,
       COALESCE(rev.amount, 0)       AS reversed,
       r.amount - COALESCE(rev.amount, 0) AS unrecovered
  FROM refunds r
  LEFT JOIN transfer_reversals rev
         ON rev.transfer_id = r.transfer_id
 WHERE r.amount > COALESCE(rev.amount, 0)
 ORDER BY unrecovered DESC;

Every row is money that left and did not come back. Run it across your full history the first time — this accumulates silently, so the first run is usually the interesting one.

Why it survives code review

Because the code looks correct. refunds.create({ charge }) is the documented call, it does what its name says, and the omission is a parameter that is not there. Reviewers see present code, not absent parameters.

The durable fix is not to remember the flag. It is to make the two event streams reconcile automatically, so the answer to "is our ledger whole" is a number somebody looks at rather than an assumption everybody makes.

gitignore is not a security control

Veristria — Fri, 21 Aug 2026 13:34:31 +0000

A .env file in .gitignore tells you one thing: the file is not in your git history. It tells you nothing about whether the value inside it is currently readable by anyone who loads your site.

Those are different questions, and only the second one describes what an attacker actually does. Nobody clones your repo. They open the deployed bundle.

Where the value actually goes

A build reads .env and then makes a decision about each variable. The decision is usually made by a prefix.

Framework	Inlined into client output
Next.js	`NEXT_PUBLIC_*`
Vite	`VITE_*`
Create React App	`REACT_APP_*`
Nuxt	`NUXT_PUBLIC_*`
Astro	`PUBLIC_*`
SvelteKit	`PUBLIC_*`

Those prefixes are not warnings. They are instructions to publish. A variable so named is compiled into JavaScript that ships to every visitor, by design, and it works exactly as intended.

The mistake is almost never that someone misunderstood the prefix. It is that a key was moved into one during a debugging session at 2am, the bug got fixed, and it never moved back.

Three places the value survives after you rotate

This is the part people miss. Rotating the key is necessary. It is not sufficient, because the old value is still sitting in artefacts nobody thinks of as artefacts.

1. Source maps. A minified bundle may not show a readable key. The .map file beside it usually does — that is its entire purpose. Shipping source maps to production is common and mostly harmless, right up until the moment it is not.

# what an attacker runs, and takes about four seconds
curl -s https://yoursite.com/_next/static/chunks/main-*.js \n  | grep -oE '(sk|pk|rk)_(live|test)_[A-Za-z0-9]{16,}'

2. Previous deploys. Every platform keeps old deployments addressable. A Vercel preview URL from three weeks ago serves the bundle from three weeks ago, containing the key from three weeks ago. Rotation does not reach backwards.

3. Build logs. CI output, deploy logs and provider dashboards retain output for weeks. One console.log in a failing build is enough, and failing builds are exactly when people add logging.

The check that means something

Stop asking whether the file is ignored. Ask whether the value is recoverable from what you shipped.

# fetch what the browser actually receives, and look in it
curl -s https://yoursite.com | grep -oE '/_next/static/chunks/[^"]+.js' \n  | sort -u | head -20 \n  | xargs -I{} curl -s "https://yoursite.com{}" \n  | grep -oE '[A-Za-z0-9_-]{32,}' | sort -u

That is crude and it is still more informative than reading .gitignore, because it operates on the artefact rather than on the intent.

What to do about the ones that are already out

In order, because the order matters:

Rotate first, investigate second. The window matters more than the root cause, and the root cause is still there in an hour.
Check the provider's logs for use. Stripe, Supabase, OpenAI and most others will tell you whether the key was used and from where. "It leaked" and "it was used" call for very different responses.
Delete or expire old deploy previews. Otherwise step 1 protected the future and nothing else.
Then fix the prefix, move the call server-side, and add the check to CI.

The general principle is worth stating plainly, because it generalises past secrets: a control that operates on your source is not a control on what you ship. The build stands between them, and the build is where the interesting mistakes live.

Your RLS policies were correct when you wrote them

Veristria — Fri, 21 Aug 2026 13:34:01 +0000

Row-level security has a property that makes it unusually easy to get wrong over time: a policy that is correct is indistinguishable from a policy that is wrong, until someone reads it.

There is no error. No failed query. A too-permissive policy returns more rows, which looks exactly like a working application. That is the whole problem in one sentence.

The four ways a policy stops being correct

None of these involve anyone editing the policy.

1. A new column arrives. You wrote USING (auth.uid() = user_id) and it was right. Then a migration added organization_id, and rows are now reachable by a user who belongs to a different organisation but happens to match on user_id. The policy did not change. Its meaning did.

2. USING was written and WITH CHECK was not. These are separate halves and people routinely write one. USING filters what a statement can see; WITH CHECK constrains what it can write. A policy with only USING will happily let a user UPDATE a row into a state where they can no longer see it — writing data they cannot read back, into someone else's tenant.

-- readable only by the owner, writable into any shape
CREATE POLICY p ON documents
  FOR ALL USING (auth.uid() = owner_id);

-- both halves
CREATE POLICY p ON documents
  FOR ALL USING (auth.uid() = owner_id)
         WITH CHECK (auth.uid() = owner_id);

3. A table was created without RLS at all. ALTER TABLE ... ENABLE ROW LEVEL SECURITY is a separate statement from CREATE TABLE. A table created by a migration, a dashboard click, or a framework generator does not have it on by default. Enabling RLS with no policies denies everything, which is safe and visible. Forgetting to enable it exposes everything, which is unsafe and invisible.

4. The service role bypasses all of it. That is what it is for. The failure is not the key existing, it is the key being used from somewhere that handles end-user input — an edge function, a server action, a webhook handler that grew a query.

Reading a policy is not testing it

This is the part worth internalising. You can read a policy, agree it looks right, and be wrong — because what it does depends on the current schema, the current role, and the current auth.uid(), none of which are in the policy text.

The test that means something is: connect as the role, set the claims, and count rows you should not be able to see.

-- as an authenticated user who owns nothing in this tenant
SET request.jwt.claims = '{"sub":"11111111-1111-1111-1111-111111111111"}';
SET ROLE authenticated;

SELECT count(*) FROM documents;   -- expect 0, not "looks fine"

If that returns a non-zero number, the policy is wrong regardless of how it reads.

The check worth automating

Three queries, run on every migration, catch most of it:

-- tables with RLS off
SELECT relname FROM pg_class c
  JOIN pg_namespace n ON n.oid = c.relnamespace
 WHERE n.nspname = 'public' AND c.relkind = 'r' AND NOT c.relrowsecurity;

-- tables with RLS on and no policies (denies all - usually unintended)
SELECT c.relname FROM pg_class c
  JOIN pg_namespace n ON n.oid = c.relnamespace
  LEFT JOIN pg_policy p ON p.polrelid = c.oid
 WHERE n.nspname = 'public' AND c.relrowsecurity AND p.oid IS NULL
 GROUP BY c.relname;

-- policies with USING and no WITH CHECK on a write command
SELECT polrelid::regclass, polname FROM pg_policy
 WHERE polwithcheck IS NULL AND polcmd IN ('a','w','*');

None of these need a tool. Run them in CI and fail the build.

The reason drift is worth monitoring rather than auditing once is in the first sentence: nothing tells you. The schema moves, the policy stays, and the gap between them opens quietly. The only way you find out is by looking, on a schedule, at something that does not change unless you check it.

Your .env file is not the problem

Veristria — Fri, 21 Aug 2026 13:24:36 +0000

Your .env file is not the problem

Originally published on keydrift.dev. Syndicated here with a canonical link back to the original.

There is a reassuring ritual in every new project. You put your keys in .env, you check that .env is in .gitignore, and you move on. The repository stays clean. Every secret scanner in CI passes.

And then the key ships to every visitor who loads your site.

What the prefix actually does

Frontend build tools do not have a runtime environment in the browser. There is no process.env on a user's machine. So when you write this:

const client = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_KEY,
);

the bundler does not pass the variable through. It performs a textual substitution at build time. The literal string value is written into the output JavaScript, and that file is served from your CDN to anyone who asks for it.

This is documented, intended behaviour. NEXT_PUBLIC_ in Next.js and VITE_ in Vite both mean "inline this value into the client bundle". The prefix is the opt-in.

The problem is not the mechanism. The problem is which variable ends up behind the prefix.

How the wrong key gets there

Consider a common sequence. You are building a feature that needs to read a table. The anon key returns nothing, because row-level security is doing its job. The feature does not work.

The fastest way to make it work is to use the service-role key instead. It bypasses RLS entirely, and the feature immediately works. To use it in client code, it needs a NEXT_PUBLIC_ prefix — otherwise it is undefined in the browser.

So NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY gets created, the feature ships, and the tests pass.

AI coding assistants make this sequence faster, not different. Asked to make a failing query work, the shortest correct-looking path is the elevated credential. The generated diff contains a variable name, not a secret. Nothing in review looks wrong, because in the source, nothing is wrong.

Why your scanners miss it

Almost every secret-scanning tool works on one of two things: your git history, or your working tree. Both are the wrong place to look.

The repository is clean. The .env was never committed. The scanner is correct when it reports nothing.
The source is clean. The code contains process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY — an identifier, not a credential. There is no high-entropy string to match on.
The build output is not scanned. It is generated on a CI runner, uploaded to a CDN, and never inspected by anything.

The secret only exists in one place: the artefact. And nothing is looking at the artefact.

What to check instead

You can do this yourself, right now, without any tooling. Open your deployed site, view source, and open one of the JavaScript chunks. Search it for eyJ — the prefix of every JWT, which is what a Supabase key is. Search for sk_live, sk-, AKIA.

If you find something, note that the fix is not to remove the string from the bundle. The key is already compromised. Anyone who loaded that page has it, and CDN caches and archives may still serve it after you deploy again. The fix is:

Rotate the key at the provider, immediately.
Move the call that needed it to a server route, an edge function or an RPC.
Give the client the publishable key and let RLS do the work it was there to do.
Redeploy, then check the new bundle to confirm the value is gone.

Not every key in a bundle is a leak

Worth saying clearly, because the opposite mistake is also expensive: some credentials belong in client-side JavaScript.

A Supabase anon key, a Stripe publishable key, a Mapbox public token, a Sentry DSN — these are designed to be public. They have recognisable formats. Reporting them as leaks trains people to ignore the tool that reported them, which is worse than not scanning at all.

The useful question is never "is there a key in the bundle". It is "is there a key in the bundle that grants more than a stranger should have".

The short version

Git-ignoring .env protects your repository. It does nothing for your bundle, because the bundle is built from the values, not from the file. If you have never looked at what your deployed JavaScript actually contains, that is the gap — and it takes about two minutes to close.

You issued the refund. They kept the money.

Veristria — Fri, 21 Aug 2026 13:24:35 +0000

You issued the refund. They kept the money.

Originally published on feeguard.dev. Syndicated here with a canonical link back to the original.

A customer asks for their money back. You refund the charge. Stripe returns the funds, the customer is satisfied, the support ticket closes.

The connected account keeps the transfer.

Nothing in that sequence is a bug. Stripe did exactly what it was asked to do. But the platform is now down the full transfer amount, and there is no error, no alert and no line item that says so.

The arithmetic

A single Connect charge involves three movements, not one.

The customer is charged. Money arrives in the platform's balance.
An application fee is taken. That is the platform's revenue.
A transfer moves the rest to the connected account.

Refunding the charge reverses movement one only. The customer's money goes back. Movements two and three are separate objects with separate lifecycles, and neither is touched unless you say so.

Take a €100 charge with a €10 application fee.

Charge: +€100 to the platform.
Application fee: €10 stays with the platform.
Transfer: €90 to the connected account.

Refund the €100 in full and, by default:

The customer gets €100 back, taken from the platform balance.
The €10 application fee is refunded too, if you asked for it — otherwise it stays.
The €90 transfer is not reversed.

Net position: the platform is €90 down on a transaction that was, a moment ago, €10 up.

The flags that decide it

Two parameters control this, and their defaults are the ones that cost money.

refund_application_fee decides whether the platform gives back its own fee. Defaulting to false is usually correct for a platform-fault refund and usually wrong for a seller-fault one.

reverse_transfer decides whether the connected account gives back what it received. This is the expensive one. It defaults to false, which means every refund issued without it leaves the seller paid in full.

await stripe.refunds.create({
  charge: 'ch_...',
  refund_application_fee: true,
  reverse_transfer: true,
});

If your refund path was written by someone reading the basic refund documentation, or generated from a prompt that said "refund the charge", these flags are almost certainly absent.

Partial refunds are worse

A full refund at least has an obvious correct answer. Partial refunds require you to decide how the loss is split, and the platform bears whatever you do not explicitly allocate.

Refund €40 of that €100 charge. What should happen?

Reverse €36 of the transfer and refund €4 of the application fee, keeping the 10% split intact? That is proportional, and usually what both parties expect.
Reverse the full €40 from the transfer and keep the €10 fee? The seller absorbs the entire refund.
Reverse nothing? The platform absorbs €40 on a transaction that earned it €10.

Stripe will do any of these. It has no view on which is right, because that is a commercial decision, not an API one. What it will not do is warn you that the third option is what your code currently implements.

Why it never surfaces

This class of loss has four properties that make it nearly invisible.

It succeeds. Every API call returns 200. There is nothing to catch, nothing to retry, nothing to log at error level.

It is per-transaction and small. €90 does not trigger anyone's finance alert. Ten thousand of them do, but by then they are spread across a year of statements.

The objects are separate. The charge, the transfer, the application fee and the refund are four different records. Noticing the gap means joining them and doing arithmetic that no default dashboard performs.

It expires. Transfer reversals have practical limits — the connected account has to have the balance, and the further back you go the more likely it does not. Discovering a leak from March in October frequently means discovering that it is no longer recoverable.

That last point is the one that matters most. This is not a problem you can defer to a quarterly reconciliation, because a quarterly reconciliation finds losses that have already aged out of recovery.

What to check today

You can do a version of this by hand. Pull your refunds from the last 90 days, and for each one ask:

Did a transfer exist for the original charge?
Was a transfer reversal created against it?
If the refund was partial, does the reversal amount match the split your terms of service promise?
Was the application fee refunded when it should have been — or kept when it should not have been?

Any row where the answer to two is "no" is money the platform paid on the seller's behalf without deciding to. Some of it is recoverable. The oldest of it probably is not, and that is the part worth fixing the code for.

Disputes have the same structure, with a shorter fuse: a lost dispute takes the charge amount and a fee, and the transfer is untouched unless you reverse it.

The short version

reverse_transfer defaults to false. If your refund path does not set it, and does not have a deliberate reason not to, every refund you have issued has been paid for by the platform. Check the last ninety days first — those are the ones you can still get back.