What you are seeing
This fix traces the payment journey from scan to confirmation and finds the step that fails. You will check the payload, the amount, the account details, and the checkout behaviour, then repair whichever step is at fault. Verify the fix with a real test payment in the same conditions your customers use.
Likely causes
1.
Wrong amount or currency in the payload — Quick test: decode the payload and compare the amount with the intended charge.
2.
Wrong account or merchant details — Quick test: confirm the account details with the payment provider record.
3.
Payment page or checkout broken — Quick test: walk through the checkout manually without the QR code.
4.
Payment method not supported — Quick test: try a different payment method on the same checkout.
5.
Expired or single-use payment link — Quick test: check the link dates and usage record.
Step-by-step fix
Step 1: Decode the payload and write down the exact payment details it carries.
Step 2: Walk through the checkout manually, without the QR code, and note where it fails.
Step 3: Compare the amount, the currency, and the account details with the intended setup.
Step 4: If the payload is wrong, regenerate the code from the corrected payment details.
Step 5: If the checkout is broken, fix the page or the payment settings and test the checkout on its own.
Step 6: If the account is not set up to receive payments, complete the setup with the provider before relaunching.
Step 7: Retest the full journey from scan to confirmation on two devices with a real test payment.
Putting this into practice
In practice, never relaunch a payment code on the strength of a scan test. Only a completed test payment, reaching a confirmation, proves the journey works. Keep that test payment in your launch checklist for every payment code. Record the before-and-after behaviour with the job file, so the fix is provable rather than anecdotal. When the same failure appears again, that record tells you whether the old fix held or a new cause appeared.
Common mistakes to avoid
- Relaunching a payment QR code after a scan test, without ever completing a test payment.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that scans but the payment fails will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans but the payment fails.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The decoded payment details match the intended charge
- The checkout works manually without the QR code
- A test payment reaches a confirmation
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [QR expiry checker](/qr-expiry-checker)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR batch validator](/qr-batch-validator)
- [QR scan log](/qr-scan-log)
- [QR safety checker](/qr-safety-checker)
- [QR payload inspector](/qr-payload-inspector)
