The checkout broke at 11 p.m. on Black Friday
A client called me at 11:07 p.m. EST on Black Friday. Her Shopify store—handmade candles, about $40k a year—was taking payments but orders weren't appearing in the admin. Customers were getting Stripe receipts, money was leaving their accounts, but the store showed nothing. She'd lost six orders in twenty minutes before someone texted her directly.
I logged into her server. The Stripe webhook endpoint was returning 200 OK. Stripe's dashboard showed every webhook attempt marked "succeeded." But the orders weren't in Shopify, and the database had no record of them. No errors in the application logs. Nothing in Stripe's event logs beyond "delivered successfully." The code had been running fine for eight months.
I copied the webhook handler code, the Stripe event payload, the server logs and the Nginx timeout config into three different AI models to see which one would find it. Claude Sonnet 4.5, Gemini Pro and DeepSeek V3. I wasn't doing a science experiment—I needed an answer before midnight, and I wanted to see which reasoning model would actually spot the problem instead of suggesting I "add more logging" or "check the API key."
DeepSeek found it in one attempt. Stripe retries webhooks for up to ten seconds if your endpoint doesn't respond. My Nginx timeout was set to five seconds. The webhook handler was calling Shopify's API to create the order, and that call was taking six to eight seconds under Black Friday load. Nginx killed the request at five seconds and returned 200 to keep the connection alive. Stripe thought it had delivered successfully. Shopify never saw the order. The payment went through, the webhook vanished, and the customer got a receipt for nothing.
I bumped the Nginx timeout to fifteen seconds, restarted, and the next order came through. The client went to bed. I stayed up and tested the other two models on the same logs to see what they'd missed.
Claude gave me a theory but missed the timeout mismatch
I pasted the webhook code first—about 80 lines of Node.js, Express, the Stripe SDK, and a function that posts the order to Shopify's API. Then I added the Nginx config and the server logs showing the 200 responses. I asked Claude: "This Stripe webhook returns 200 but orders aren't reaching Shopify. What's wrong?"
Claude's first response was thoughtful. It suggested the Shopify API call might be failing silently, and that I should wrap it in a try-catch and log the error. Fair advice, but the code already had that. I told Claude there were no errors in the logs. It pivoted: maybe the webhook signature verification was passing but the event type was wrong, so the handler was exiting early without processing the charge. I checked—event type was checkout.session.completed, exactly what the code expected.
Claude asked to see the full logs. I pasted twenty lines showing the webhook received, signature verified, and the 200 response sent. Claude said, "It looks like the response is being sent before the Shopify API call completes. You should await the Shopify call before sending the response." I told it the code already did that—await shopify.createOrder(...) then res.status(200).send().
Third attempt, Claude suggested the Nginx timeout might be cutting off the request. That was closer, but it didn't connect the dots. It said "check if Nginx is timing out" without noticing the five-second config I'd pasted earlier or the fact that Stripe retries for ten. It gave me the right area to investigate but didn't solve it.
Claude is great for talking through a problem when you're stuck. It asks good follow-up questions and suggests angles you might not have considered. But it didn't read the config closely enough to spot the mismatch on its own.
Gemini found three problems, two of them imaginary
Gemini Pro came back fast—maybe three seconds—with a numbered list of five possible causes. The first was "webhook signature verification might be failing intermittently." I'd already told it the signature was verified in the logs. The second was "Shopify API rate limiting," which would throw an error, not silently succeed. The third was "database transaction not committing," even though I hadn't mentioned a database transaction in the code.
I narrowed the prompt: "The code works. The signature is valid. The logs show 200. Orders aren't appearing. The Nginx timeout is five seconds. Stripe retries for ten seconds. What's happening?"
Gemini said, "If Nginx times out at five seconds and Stripe retries for ten, the request might be cut off mid-flight, but that would return a 504 or 502, not 200." Wrong—Nginx was returning 200 because I'd configured it to close the connection gracefully on timeout to avoid spamming the logs with errors. Gemini assumed default behaviour and missed the actual config.
I liked Gemini's speed, and the numbered list format made it easy to scan. But it invented problems that didn't exist and didn't slow down to check the details. If you're debugging under pressure and you don't know what's wrong, Gemini will give you ten things to check. Half of them will waste your time.
DeepSeek read the config, did the math and solved it
I gave DeepSeek the same inputs: code, Nginx config, logs, the symptom. I added, "Orders are paid but not appearing in Shopify. Stripe shows webhook delivered. No errors."
DeepSeek's response was longer—maybe 300 words—but the first paragraph said: "Your Nginx timeout is five seconds. The Shopify API call is taking six to eight seconds under load. Nginx closes the connection and returns 200 to avoid breaking the client. Stripe sees a successful delivery and doesn't retry. The order is lost."
It walked through the sequence: webhook arrives, handler starts, Shopify API call begins, five seconds pass, Nginx kills the request, handler never finishes, Shopify never receives the order, but Stripe's logs show success because Nginx returned 200 before closing. Then it suggested raising the Nginx timeout to fifteen seconds and adding a queue so the webhook can return immediately and process the order asynchronously.
That was it. One attempt, correct diagnosis, two solutions. I implemented the timeout fix in two minutes. The queue idea was smart but not urgent—I filed it for after the weekend.
DeepSeek's reasoning models (V3 and R1) are built to follow chains of logic, especially in code. It read the five-second timeout, saw the Shopify API call, noticed there were no errors, and concluded the request was being cut off before completion. Claude and Gemini both needed more hand-holding.
When to use each model for debugging
I've been using all three for the past month on client work—Shopify apps, Stripe integrations, webhook handlers, API wrappers. Each one has a different debugging style.
Claude is best when you don't know where to start. Paste the code, describe the symptom, and let it ask questions. It'll suggest five or six areas to investigate, and one of them will usually be right. I use Claude for "this is broken and I have no idea why" situations, especially when the error message is vague or missing. It's patient, and it doesn't jump to conclusions.
Gemini is fast and good for surface-level checks. If you think you know what's wrong but want a second opinion, Gemini will confirm or suggest an alternative in a few seconds. I use it for code review—paste a function, ask if there's a security issue or an edge case I missed. It's not great at deep reasoning, but it's fast enough that I'll throw a question at it while I'm still reading the logs.
DeepSeek is the one I reach for when the bug is subtle and involves timing, async behaviour, or config mismatches. It's slower than Gemini—maybe ten seconds for a detailed answer—but it actually reads the code and the config and thinks through the sequence of events. I used it last week to debug a race condition in a webhook that was firing twice. DeepSeek traced the flow, spotted that I was sending the response before updating a database flag, and suggested moving the response to the end. Claude had suggested adding a mutex. Gemini suggested rate limiting. DeepSeek was right.
If you're debugging Stripe webhooks specifically, start with DeepSeek. Webhooks are all about timing and retries and what happens when your server is slow. DeepSeek handles that kind of reasoning better than the others.
The async queue I should have built in the first place
DeepSeek's second suggestion—processing the order asynchronously—was the better long-term fix. Webhooks should return 200 as fast as possible, ideally under one second. If you're calling a slow external API like Shopify, you should queue the work and process it in the background.
I rebuilt the handler the weekend after Black Friday. The webhook now writes the Stripe event to a Redis queue and returns 200 immediately. A separate worker pulls events off the queue and calls Shopify. If Shopify is slow or down, the worker retries. If it fails five times, I get an alert. The webhook itself never times out because it's not doing any real work.
I tested the new version with Claude. I pasted the code and asked, "What breaks if Redis goes down?" Claude said the webhook would fail and Stripe would retry, but I'd lose the event if Redis stayed down for ten seconds. Fair point. I added a fallback: if Redis is unreachable, write the event to a file and process it later. Claude suggested adding a health check endpoint so I'd know if Redis was down before the webhook fired. I added that too.
Gemini would have told me to add error handling. DeepSeek would have suggested the queue in the first place. Claude helped me think through the edge cases once I had a solution. All three models are useful, but at different stages.
Questions people ask
Which model is fastest for debugging?
Gemini Pro by a lot—usually three to five seconds. DeepSeek V3 takes ten to fifteen seconds for a detailed answer. Claude Sonnet 4.5 is somewhere in between, maybe six to eight seconds. If you need a quick sanity check, use Gemini. If you need the right answer, use DeepSeek.
Can these models read server logs and find errors automatically?
Yes, but you have to paste the relevant lines. I'll copy twenty to fifty lines of logs around the failure, add a sentence describing what I expected to happen, and ask what went wrong. DeepSeek is the best at spotting patterns—missing fields, timing issues, truncated responses. Claude asks clarifying questions. Gemini gives you a list of possibilities.
Do I need to know which model to use before I start?
Not really. I usually start with Claude because it's conversational and I can paste messy context without cleaning it up first. If Claude doesn't find it quickly, I switch to DeepSeek and give it the same logs plus Claude's suggestions. Gemini I use for a second opinion or when I'm in a hurry and just want a checklist.
Is DeepSeek better than Claude for all coding tasks?
No. DeepSeek is better at reasoning through logic and config. Claude is better at explaining code, suggesting refactors, and talking through architecture decisions. I use Claude when I'm planning, DeepSeek when I'm debugging, and Gemini when I need something checked fast.
Kryotta lets you switch between all three models in the same workspace, so you can try Claude first, paste the conversation into a DeepSeek thread if you're not getting anywhere, and compare the answers side by side. I've been doing that for every tricky bug since Black Friday. One of them usually finds it.
If you're debugging webhooks, API timeouts, or anything involving async behaviour and retries, start here: app.kryotta.ai/auth
