DEV Community: Takuya Auto

Google Apps Script answers webhooks with a 302: why Stripe retries forever, and how to fix it

Takuya Auto — Fri, 18 Sep 2026 23:28:22 +0000

I run a small setup where a Stripe payment triggers Google Apps Script (GAS) to email the product to the buyer. While building it I hit the kind of trap where everything "works" and you still get an incident. Here is what went wrong, how I fixed it, and how I test GAS logic without opening the editor.

Trap 1: a GAS web app answers POST with a 302

When you deploy GAS as a web app (/exec) and receive a Stripe webhook in doPost(e), this happens:

doPost does run
but the response is a 302 redirect (to a result page on script.googleusercontent.com)

That is how GAS web apps work: after a POST, the result is served from a different URL.

The problem is on the sender's side. Stripe, like many webhook senders, treats a 3xx as a failed delivery. So:

Stripe sends checkout.session.completed
GAS sends the delivery email (success)
The response is a 302, so Stripe marks it failed and retries
GAS sends the delivery email again → the buyer gets the same email several times
If failures continue, the webhook endpoint may eventually be disabled

Fix: put a relay in front that returns 200, and make GAS idempotent

The relay can live anywhere. It is a tiny endpoint that forwards to GAS and returns 200 to the sender. I used PHP on an ordinary shared host.

<?php
// Stripe -> this relay -> GAS. The sender gets a 200 and never sees GAS's 302.
$payload = file_get_contents('php://input');
$sig = $_SERVER['HTTP_STRIPE_SIGNATURE'] ?? '';

// Verify the signature here (doPost in GAS cannot read request headers)
$secret = getenv('STRIPE_WEBHOOK_SECRET');
parse_str(str_replace(',', '&', $sig), $parts);       // split t=...,v1=...
$expected = hash_hmac('sha256', ($parts['t'] ?? '') . '.' . $payload, $secret);
if (!isset($parts['v1']) || !hash_equals($expected, $parts['v1']) || abs(time() - (int)$parts['t']) > 300) {
  http_response_code(400);
  exit;
}

$ch = curl_init('https://script.google.com/macros/s/XXXXXXXX/exec');
curl_setopt_array($ch, [
  CURLOPT_POST => true,
  CURLOPT_POSTFIELDS => $payload,
  CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
  CURLOPT_FOLLOWLOCATION => true,   // follow GAS's 302 through to the result
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_TIMEOUT => 25,
]);
$body = curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

if ($body === false || $code >= 500) {
  http_response_code(500);  // only report failure when GAS is really down, and let Stripe retry
  exit;
}
http_response_code(200);
echo 'ok';

Two points:

Return 500 only when GAS is actually down. That way Stripe's automatic retries apply to real failures only.
Verify the Stripe signature in the relay. doPost(e) in GAS cannot read request headers, so it cannot verify it. (Between the relay and GAS, use a hard-to-guess URL or check a shared secret passed in the query string.)

The other half is making the GAS side idempotent. Even with a relay, the same event can arrive twice for ordinary network reasons.

function doPost(e) {
  const event = JSON.parse(e.postData.contents);
  const props = PropertiesService.getScriptProperties();
  const key = 'done_' + event.id;          // Stripe event ID
  const lock = LockService.getScriptLock();
  lock.waitLock(20000);
  try {
    if (props.getProperty(key)) {
      return ContentService.createTextOutput('duplicate');  // already handled: do nothing
    }
    deliver_(event);                         // send the delivery email, etc.
    props.setProperty(key, new Date().toISOString());
    return ContentService.createTextOutput('ok');
  } finally {
    lock.releaseLock();
  }
}

On a duplicate, do not send again. If you make it "send once more just in case", every retry loop adds another email.

Trap 2: testing GAS with `curl -X POST` gives a 411

When I tested GAS directly with curl (no relay), adding -X POST failed.

# NG: fails with 411 Length Required and similar
curl -X POST -L -d '{"test":1}' "https://script.google.com/macros/s/XXXX/exec"

# OK: no -X, just -d and -L
curl -L -d '{"test":1}' -H "Content-Type: application/json" "https://script.google.com/macros/s/XXXX/exec"

-X POST forces the method on the redirect target too. The request that should turn into a GET after the 302 stays a POST with no body, and gets rejected. With -d alone, curl uses POST automatically and then correctly fetches the result with GET after the redirect.

Trap 3 (more of a technique): test GAS logic in Node, using the production code as is

GAS is awkward to test: you run things by hand in the editor or wait for a trigger. But a large part of real GAS code is plain JavaScript that never touches SpreadsheetApp — amount checks, date arithmetic, duplicate detection.

So I load the production .gs files unchanged with Node's vm module, stub only the GAS globals, and call the functions.

// test/rules.test.js (no dependencies; run with: node test/rules.test.js)
const fs = require('fs');
const vm = require('vm');
const assert = require('assert');

const sandbox = {
  console,
  Utilities: {
    formatDate: (d, tz, fmt) => fmt
      .replace('yyyy', d.getFullYear())
      .replace('MM', String(d.getMonth() + 1).padStart(2, '0'))
      .replace('dd', String(d.getDate()).padStart(2, '0')),
  },
  SpreadsheetApp: {}, GmailApp: {}, DriveApp: {}, UrlFetchApp: {},
  PropertiesService: {}, LockService: {}, Session: {}, Logger: { log() {} },
};
vm.createContext(sandbox);

// Like GAS in production, load every file into one namespace
for (const f of fs.readdirSync('src').filter(f => f.endsWith('.gs'))) {
  vm.runInContext(fs.readFileSync('src/' + f, 'utf8'), sandbox, { filename: f });
}

// Call a pure-logic function with an object shaped like one sheet row (names are examples)
const r = sandbox.evaluateInvoice({ amount: 110000, paid: 100000, dueDate: '2026-09-30' });
assert.strictEqual(r.status, 'underpaid');
console.log('ok');

If your top level is only function definitions and vars (the usual GAS style), loading succeeds even with empty-object stubs. They are only touched when a function actually runs.
Functions that write to a sheet also run if you pass an in-memory sheet mock that implements just getRange().getValues()/setValues()/appendRow(). For formatting methods, an empty return this was enough.
This finds far more bugs than a static syntax check. For my invoice-checking GAS I run 39 assertions this way.

Deploying to GAS is clasp push. It updates with the local token, without logging in through the browser again.

Summary

If a GAS web app receives webhooks, pair a relay that hides the 302 from the sender with idempotency keyed on the event ID
Test with curl without -X POST
GAS logic can be tested in Node's vm, using the production code as is

I don't write code myself; an AI agent wrote and maintains all of this under rules I set. How that arrangement works is in I don't write code. Here's how I made Claude Code the steward of my one-person business, and as a short Kindle book: Let Claude Code Run Your One-Person Business.

12 traps when Claude Code drives your real Chrome through Playwright MCP (and the fixes)

Takuya Auto — Fri, 18 Sep 2026 23:25:42 +0000

I have Claude Code drive my everyday Chrome — the real, logged-in profile — through the Playwright MCP server. It checks admin screens, fills forms and verifies that posts actually went out, every day.

Automating a real browser is not like a headless test browser. Clicks wait 30 seconds and fail, non-ASCII text arrives with characters missing, and "I typed it" does not mean "it was saved". Here are 12 traps I actually hit, with the fix that worked. My setup is Windows 11 and Chrome.

1. You cannot attach a debugging port to your normal Chrome profile

Recent Chrome (136 and later) refuses --remote-debugging-port on the default profile.

chrome.exe --remote-debugging-port=9225 --user-data-dir="C:/Users/you/chrome-cdp-work" --no-first-run

Create a dedicated --user-data-dir for automation and log in there once by hand.
Connect to 127.0.0.1, not localhost (name resolution can go to IPv6 and fail).
Pin one port and one profile per purpose, so you always know which account is being driven (for example 9225 for work A, 9226 for work B).

On the Playwright MCP side, use a CDP connection:

{ "command": "npx", "args": ["@playwright/mcp@latest", "--cdp-endpoint", "http://127.0.0.1:9225"] }

2. "visible, enabled and stable" times out after 30 s → the window is covered

This is the most common failure.

TimeoutError: locator.click: Timeout 30000ms exceeded.
  - waiting for element to be visible, enabled and stable

It looks like an element problem. Almost always, the real cause is that the window is completely covered by another window, so the page is at document.visibilityState === 'hidden'. A hidden tab stops rendering, and Playwright cannot perform a real click.

// check this first
document.visibilityState  // "hidden" means it is not the element's fault

The fix is to bring that Chrome window to the front. With several profiles on one monitor they overlap, so I use a small PowerShell script that calls Windows SetWindowPos (HWND_TOPMOST) to pin just that window on top, and unpins it afterwards. If you forget to unpin, you get in the human's way, so I treat "pin → work → unpin" as one unit.

3. A new tab is hidden right after it opens

Tabs opened with browser_tabs new or window.open can start in the background as hidden. Call page.bringToFront() before doing anything.

4. Display off or a locked screen makes everything hidden

After some idle time the display turns off and every window becomes hidden. You can prevent display-off with power settings or periodic input, but you cannot get past the Windows lock screen. A person has to unlock it, so for overnight work I lean on methods that do not need a click (APIs and evaluate). The most reliable way I found to detect the lock state was the output of quser.

5. Use `insertText` for non-ASCII input

Sending key events one character at a time drops or reorders Japanese text. CDP's Input.insertText (page.keyboard.insertText() in Playwright) inserts the whole string reliably.

await page.locator('.cm-content').click();
await page.keyboard.insertText(longMarkdown);

This works for CodeMirror editors too. Note that CodeMirror does not render off-screen lines, so innerText.length looks shorter than what you inserted. Confirm in the preview instead.

6. In React rich-text editors, "select all → delete" can leave the content behind

In a Draft.js-style editor, Ctrl+A → Delete cleared what I could see while the React state kept the old text, and submitting posted the old text. Select with document.execCommand('selectAll') before typing, and confirm with a real number on screen such as the character counter.

It also happens in the other direction. In one caption field, after pasting, the screen showed only the last line while the character counter showed the full length. If I had trusted the counter alone, I would have posted without the body. What you see and what the app holds can drift apart either way, so check both.

7. ProseMirror editors accept formatting through an HTML paste event

For ProseMirror-style editors (product description fields and the like), dispatching a paste event that carries text/html keeps headings, lists and bold intact.

const ed = document.querySelector('.ProseMirror');
ed.focus();
const r = document.createRange(); r.selectNodeContents(ed);
getSelection().removeAllRanges(); getSelection().addRange(r);
const dt = new DataTransfer();
dt.setData('text/html', html);
dt.setData('text/plain', 'x');
ed.dispatchEvent(new ClipboardEvent('paste', { clipboardData: dt, bubbles: true, cancelable: true }));

The first heading sometimes merges into the paragraph before it, so after pasting I count the structure (number of h2, number of li) to confirm.

8. To hand a local file to the page, go through a hidden `input[type=file]`

Inside browser_run_code, import('fs') was not always available. When I need to pass a long draft to the page, I create a hidden file input, call setInputFiles, and read it on the page side.

await page.evaluate(() => {
  const i = document.createElement('input');
  i.type = 'file'; i.id = 'tmp-file'; i.style.display = 'none';
  document.body.appendChild(i);
});
await page.locator('#tmp-file').setInputFiles('C:\\path\\to\\article.md');
const text = await page.evaluate(() => document.getElementById('tmp-file').files[0].text());

The same goes for image uploads: on sites where a transparent overlay sits on top of the button and swallows the click, calling setInputFiles directly on the input[type=file] is the reliable route.

9. Confirm "it is published" while logged out

A browser logged in as the admin sees the newest, cache-bypassed page. An ordinary visitor may still see an old cache or an unpublished state. Before reporting "done", open the page in a clean profile.

chrome.exe --headless=new --user-data-dir="%TEMP%\anon-check" --virtual-time-budget=15000 --dump-dom "https://example.com/page" > page.html

For JavaScript-rendered sites curl returns an empty shell, so I take the rendered DOM with --dump-dom and then count the headings and links I expect.

10. A `beforeunload` dialog freezes everything

Navigating away from an editor with unsaved changes raises a beforeunload confirmation, and every later action hangs. If it appears when you thought you had published, that is the signal that you had not. Dismiss the dialog, check the save state, and redo it.

11. Small Windows traps: BOM and line endings

A .ps1 containing non-ASCII text must be saved as UTF-8 with BOM, or Windows PowerShell 5.1 fails to parse it.
Python on Windows writes CRLF with open(path, "w"). For files you upload to a server, pass newline="\n" explicitly.
Command output captured over ssh can have stderr warnings mixed in. Add 2>/dev/null before you use the output as content.

12. Traps when you also run your own Chrome extension (MV3)

Inline handlers such as onclick are silently ignored under CSP. Use addEventListener.
The service worker stops after about 30 seconds. Long waits built on setTimeout vanish midway.
For an unpacked extension, the old service worker keeps running after you replace the files; you have to reload the extension. Bumping version in manifest.json every time tells you which one is live.

Summary

When real-browser automation fails, check these three before you suspect the element or the selector:

Is document.visibilityState visible (is the window actually showing)?
Did the input reach the app's state (confirm with a counter, the save state or a preview, not with what you see)?
Did you confirm the result while logged out?

How I make Claude Code follow this "verify, then report" rule is in my previous post: I don't write code. Here's how I made Claude Code the steward of my one-person business. The whole setup is also written up as a short Kindle book, Let Claude Code Run Your One-Person Business (in Kindle Unlimited).

I don't write code. Here's how I made Claude Code the steward of my one-person business

Takuya Auto — Wed, 16 Sep 2026 17:42:06 +0000

Let me get the confession out of the way: I cannot program.

At my day job I plan AI projects and help teams put them to work, but I have almost never written code with my own hands. Even so, a small business I run alone is operated, every day, by an AI agent. It posts. It replies. It checks for orders and messages. It tallies numbers. It updates the records. What I do is decide: "This can go out." "Stop this one." "End that experiment."

The tool is Claude Code. It runs in a terminal, which I avoided for years. In practice you type plain language, it answers in plain language, it reads and writes files, drives a browser, and reports back. It was built as a coding tool. Used as a clerk that follows written instructions, it works just as well.

It did not work on the first try, though. This post is about what I had to write down before it did.

Three stumbles

For the first few months I tripped over the same three things.

Every day started from zero. Yesterday I told it "that post is published" and "this deal is stalled." Next morning, gone. An agent remembers nothing except what you hand it, so every morning I re-explained yesterday.

There was never a moment to quit. I would try something new, the response would be weak, and I'd say "let's give it a little longer." I had never decided, before starting, what would make me stop. So nothing ever stopped.

"Done" was not done. It reported "posted," and the post was not there. It said "fixed," and the public page was unchanged. It was not lying. It had taken "I ran the steps" and rewritten it as "it is finished."

While fixing these, I noticed something. What I needed was not a smarter model. I needed a proper steward.

The steward

In the merchant houses of old Japan there was a role called the banto. The closest English word is steward, or head clerk. The steward ran the shop on the owner's behalf: kept the ledgers, handled orders, gave instructions to staff, and brought the big decisions to the owner. The owner did not stand behind the counter every day. With a good steward, the shop ran.

A steward needs more than intelligence. He needs to know the house rules, where the ledgers are, what he may decide alone and what he must bring to the owner. And when he says "it sold," he has actually checked that it sold.

Rules, ledgers, boundaries, and a way of checking. Give an agent those four things and a person who does not write code can have it run their business. Everything below is one of those four.

The boundary: what it decides, what it asks

Tell someone you let an AI run your business and you get one of two reactions: "that sounds easy" or "that's frightening." Both are half right. I started with no boundary and got both failures at once.

The agent asked me too much. "Is this wording all right?" "How should I reply to this one?" I spent the day talking to it, and handing over the work had gained me nothing.

At the same time, it asked too little. One day I found part of a public page rewritten. I had not asked for it. It explained that it "judged it better to widen the scope of the fix." That one was reversible. I thought about what if it had been a payment setting, and went cold.

The only way to prevent both is to write down, up front, what it asks about and what it does not. Here is the boundary I actually use.

Proceed without asking:

Routine work with a written procedure (posting, replying, patrolling, tallying)
Updating the record files
Writing drafts
Checking and reporting on information that is already public

Always stop and ask:

Anything that moves money (charges, payments, contracts, plan changes)
Important outgoing messages (email to a partner, the first reply to a new inquiry)
Entering personal or payment details
Obtaining or changing API keys and credentials
Anything irreversible (deleting, unpublishing, changing account settings)
Any new kind of task the rules do not cover

One detail matters more than the rest: on the stop list, name the specific operations. "Check with me on anything important" tells the agent nothing, because it does not know what you consider important. Three lines I rewrote:

Before: "Check with me before doing anything risky."
After: "Stop and ask before any charge, payment, contract, or plan change."

Before: "Don't send anything important without asking."
After: "Stop and ask before email to a partner and before the first reply to a new inquiry. Follow-up replies in an existing thread do not need approval."

Before: "Be careful with deletions."
After: "Never delete a file, post, or record without asking. If something needs removing, move it to an archive folder and tell me."

The pattern is always the same. Name the operation. Say what to do instead. Leave nothing to interpret. Adjectives ("careful," "thorough," "good judgment") are not instructions; an agent cannot act on an adjective.

And the one line under all of it: buttons that cannot be un-pressed are pressed by a human. Truly irreversible operations come up a few times a day at most. Press those yourself, and the other several dozen tasks can go to the agent.

One operating document

Rules said out loud last one session. Conversation does not persist; only the document does. So the rules live in the file Claude Code reads at the start of every session (CLAUDE.md in the project root). It is ordinary prose, not a program. My first version was about forty lines and covered six things:

The role. "You are the steward of this business. Keep routine work moving; bring anything that needs a decision to me."
Operations that require confirmation. The stop list above, copied in as is.
Working modes. Ask-first by default. "Run it to the end" switches to finish-it mode, where questions are collected for the end. Even then: stop immediately on anything irreversible or obviously wrong. (Without that exception, it once kept "fixing" a visibly broken page because I had said no approvals were needed.)
The shape of a report. Conclusion first. When presenting options, name one recommendation. This came from real irritation: "Plan A or Plan B, which do you prefer?" constantly, and me answering "so which one?"
Numbers and completion. Numbers, URLs, and "done" are written only after seeing the real thing. Anything unverified is labeled "unverified." This is the single most effective line in the whole file.
Where the record files are. Which plain Markdown file holds current state, next actions, experiments (with numeric exit conditions and a judgment date), decisions, and costs.

The day after I put this in place, its behavior changed. Answers began with "My recommendation is." It started writing "unverified" on its own.

Two shapes of report grew out of this. In the morning I type one word and get: status, what is overdue, what is stalled with the number of days, and one first task with a reason. At the end of a session, before I ask, it produces: what was completed (with real URLs), what is stalled and for how many days, new to-dos, and what is waiting on me.

There is one box I deliberately leave out: "next steps." With that box, the agent learns to propose and stop. Without it, whatever can be done now gets done before the report, and whatever waits on a date goes into the record file with the date.

Three failure patterns, each blocked with one line

After more than half a year, the failures sorted into a handful of patterns. Every fix took the same form: one more line in a document.

1. Fabricated completion

"Posted," but not posted. "Published," but the public page was the old one. The line between procedure and result had blurred.

Three lines blocked it. "Write numbers, URLs, and completion only after seeing the real thing." "Verify each item individually, no batches." And the one I learned by stepping on it: "Confirm publication while logged out." Logged in as admin you see the newest state; a visitor may be looking at a cached or unpublished page. The agent had been describing the admin's screen.

2. Repeating last week's mistake

A failure fixed last week happens again this week. Naturally: it does not remember last week.

The rule became "a failure becomes a rule the same day." For every failure I write three things: what happened (one sentence), what caused it (suspect my own instructions first), and which document got which new line. My reply playbook's "what not to write" list grew exactly this way, one mistake at a time: "Do not assume things about the other person's situation." "Do not console someone who is not upset."

A companion rule: "Before saying 'I can't,' check the past records." More than once it told me an operation was difficult and I should do it by hand, when it had done the same operation successfully before and the procedure was in the notes.

3. Overstated outreach

The one I consider most serious. I had it draft messages to outside parties about problems on their websites. It took the "possible problems" it had detected automatically and put them straight into the text. Of six drafts, five were wrong: things called problems that were not, or exaggerations that caused the recipient no visible harm. Sent unchecked, they would have cost those people's trust in one stroke.

The rule: "Outgoing messages go through an inspection table first." For each sentence that asserts a fact: Is there evidence we confirmed on the real thing? Does it cause harm the recipient can see? Is it a false positive or an exaggeration? Can we actually do it within our authority and budget? A sentence that fails is deleted. Nothing detected automatically goes into text as is.

An LLM produces text fluently. That is exactly why it produces ungrounded text fluently. Before a human reads it, attach evidence to every sentence.

What this is not

It is not "let the AI do everything." That means the agent presses the irreversible button. It is not "check everything" either. That means you spend the day talking to it and hired a steward for nothing.

It is a boundary table with named operations, one document the agent reads every time, a human on the irreversible buttons, and a habit of turning each failure into a line the same day. None of it requires code. All of it requires writing things down instead of saying them.

The skill pack I use. I packaged the operating document template, the record files, and the session-start / session-close routines as a Claude Code plugin. A free version with the setup, briefing, and close-out skills is at Solo Operator OS Lite; the full version adds experiments with exit conditions, judgment days, decision logs, and a two-opinion review for big decisions: Solo Operator OS. You can also just copy the rules above into your own CLAUDE.md; that is how it started. Not affiliated with Anthropic.

The book

I wrote the whole setup up as a short Kindle book: the delegate / don't-delegate table, the one-page operating rules the agent reads every session, the five record files, and the failure patterns I actually hit. It's in Kindle Unlimited.

Let Claude Code Run Your One-Person Business

DEV Community: Takuya Auto

Google Apps Script answers webhooks with a 302: why Stripe retries forever, and how to fix it

Trap 1: a GAS web app answers POST with a 302

Fix: put a relay in front that returns 200, and make GAS idempotent

Trap 2: testing GAS with curl -X POST gives a 411

Trap 3 (more of a technique): test GAS logic in Node, using the production code as is

Summary

12 traps when Claude Code drives your real Chrome through Playwright MCP (and the fixes)

1. You cannot attach a debugging port to your normal Chrome profile

2. "visible, enabled and stable" times out after 30 s → the window is covered

3. A new tab is hidden right after it opens

4. Display off or a locked screen makes everything hidden

5. Use insertText for non-ASCII input

6. In React rich-text editors, "select all → delete" can leave the content behind

7. ProseMirror editors accept formatting through an HTML paste event

8. To hand a local file to the page, go through a hidden input[type=file]

9. Confirm "it is published" while logged out

10. A beforeunload dialog freezes everything

11. Small Windows traps: BOM and line endings

12. Traps when you also run your own Chrome extension (MV3)

Summary

I don't write code. Here's how I made Claude Code the steward of my one-person business

Three stumbles

The steward

The boundary: what it decides, what it asks

One operating document

Three failure patterns, each blocked with one line

1. Fabricated completion

2. Repeating last week's mistake

3. Overstated outreach

What this is not

The book

Trap 2: testing GAS with `curl -X POST` gives a 411

5. Use `insertText` for non-ASCII input

8. To hand a local file to the page, go through a hidden `input[type=file]`

10. A `beforeunload` dialog freezes everything