A Canadian private education institute hired me to fix a critical problem in their live payment system: the payment scheduler was running three days ahead of schedule. Payments were being triggered before they were due, and the institute's accounting team knew something was wrong but couldn't pin down why.
To make it harder, I hadn't written a single line of that codebase. That's a normal situation for a freelance developer, and it's when a calm, repeatable process matters most. Guessing at fixes on a live payment system is how one bug turns into three.
This is the 7-step method I followed. It works for any bug in code you didn't write, and it matters most when real money is involved.
1. Listen carefully to the client
The most important step is also the easiest to rush. Clients usually know something is wrong, but they may not be able to describe it in technical terms, and that's fine. Your job is to collect what they've seen.
Ask questions, and use every channel that helps: email, WhatsApp, a Zoom call with screen sharing. In this project the key information came from the institute's remote accounting staff. They had noticed the inconsistencies in their day-to-day work, even though they couldn't see the root cause.
Good questions to ask:
- When did you first notice it? Did anything change around that time?
- Which payments or customers are affected, and which aren't?
- What should have happened, and what actually happened?
- Who on your team sees the effects first?
2. Confirm what you learned
Before touching the code, repeat the problem back to the client in your own words. For example: "Scheduled payments are being taken three days before their due date. Is that right, and is it all payments or only some?"
This takes five minutes and can save hours. If your summary and the client's understanding don't match, you'd be debugging the wrong problem. Keep clarifying until you both agree on exactly what "broken" means.
3. Find data that reproduces the bug
Once the problem is clearly defined, find a dataset that shows the bug happening: specific payments, accounts or dates where the wrong behaviour can be seen. This is often the real key to the root cause.
You'll usually need the client's help, for example access to historical records, payment logs or the scheduler's run history. For a payment system, work from a copy or a read-only view of the data, never by experimenting on live records.
4. Check that data with the client
Before going further, confirm with the client that your dataset really represents the problem. A record that looks wrong to you might be a legitimate exception the business made on purpose.
It's a quick check, and it means you'll fix the bug the client actually has, not one you assumed.
5. Look for the pattern
With reliable data in hand, look for what the affected cases have in common:
- Does it only happen on certain dates, such as month ends, weekends or around holidays?
- Only for certain users, plans or payment types?
- Only in certain transaction states, such as renewals, retries or rescheduled payments?
Once you can say "it happens when X", you're halfway to the fix. The pattern tells you which part of the code to read.
6. Find and fix the problem code
Now trace the logic in the codebase that matches the pattern you found. In an unfamiliar system, don't try to understand everything. Follow the one path the bug takes.
If needed, isolate the functionality involved (for example, subscription auto-renewals) and write a small dry-run script that simulates it against real data without charging anyone. You can then see exactly which payments the code would pick, and when, before and after your change.
When the logic says a payment runs early, these are the usual places to check:
- Date and time-zone handling: a server in UTC and a business in a local time zone can shift dates.
- "Days before" settings: reminders, grace periods or pre-authorisation windows that get mixed up with the actual charge date.
- Date arithmetic: adding or subtracting days, month lengths and off-by-one comparisons.
- The cron or job schedule versus the due-date check inside the job.
Make the smallest change that fixes the faulty logic, and write down why.
7. Test thoroughly, then test with the client
Test the fix with the same dataset and pattern that exposed the bug. The dry-run script is perfect for this: run it before and after, and compare which payments would be processed.
When you're confident, ask the client to confirm the result from their side. Their accounting team knows what "correct" looks like better than anyone. Testing together also builds trust: the client sees exactly what was wrong and why it's fixed.
Safety rules for debugging live payment systems
- Never test on live customers. Use dry runs, a staging copy or read-only queries.
- Take a backup before changing anything in production, and have a rollback plan.
- Change one thing at a time, so you know what fixed it.
- Keep the client informed. Short, regular updates calm a stressful situation.
- Document the root cause and the fix, so the next developer, maybe you, doesn't start from zero.
Final thoughts
Fixing bugs in someone else's live system can be daunting, especially when it handles payments. But a methodical, client-centred approach turns it into a manageable problem: listen, confirm, reproduce, find the pattern, fix and test together. You solve the bug and you also earn the client's trust, which is what turns a one-off fix into a long-term working relationship.
Is your payment system, subscription renewal or WooCommerce checkout misbehaving? I fix payment and integration problems in existing codebases, carefully and without putting your live site at risk. Tell me what's happening and I'll reply within a few hours.