What you are seeing
This fix makes the contact code save a complete, correct contact. You will decode the payload, compare it with the standard format, and rebuild it with the contact generator. Verify the fix by scanning and confirming every field lands in the right place on two phones.
Likely causes
1.
Mixed or non-standard format — Quick test: decode the payload and compare it with the standard format.
2.
Field name the phone does not recognise — Quick test: check each field name against the standard list.
3.
Special characters breaking the format — Quick test: try a simple contact with plain characters and compare.
4.
Too many fields for the phone to handle — Quick test: try a minimal contact with name and phone only.
5.
Phone permission or app handling — Quick test: check whether the phone shows a save prompt at all.
Step-by-step fix
Step 1: Decode the payload and write down every field it carries.
Step 2: Compare the format and the field names with the standard contact format.
Step 3: Rebuild a minimal contact with the contact generator: name and phone only.
Step 4: Scan the minimal contact on two phones and confirm it saves.
Step 5: Add the remaining fields one group at a time, retesting after each group.
Step 6: Simplify any value with special characters that breaks the save, and retest.
Step 7: Retest the full contact on two phones and confirm every field lands in the right place.
Putting this into practice
In practice, keep the contact payload to the fields visitors actually need. Every extra field is another chance for a parsing fault, and a contact with the essential fields that saves beats a complete contact that does not. 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
- Packing every possible field into a contact code and never testing whether it saves on a real phone.
- 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 contact will not save 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 contact will not save.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The payload uses the standard contact format
- A minimal contact saves on two phones
- The full contact saves with every field in place
- 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
- [MeCard QR code generator](/mecard-qr-code-generator)
- [vCard QR code generator](/vcard-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR offline verifier](/qr-offline-verifier)
- [QR scan log](/qr-scan-log)
- [blog](/blog)
