Email is tough: Major European Payment Processor's Emails aren't RFC-Compliant
Source: Hacker News
TL;DR: Viva.com, one of Europe’s largest payment processors, sends verification emails without a Message-ID header — a basic requirement of RFC 5322 since 2008. Google Workspace rejects them outright. Their support team’s response to my detailed bug report: “your account has a verified email, so there’s no problem.”
The verification email that never arrived
The signup flow is standard: enter your email, receive a verification link, click it, move on with your life. Except the verification email never showed up. Not in my inbox, not in spam, not anywhere. I waited. I retried. I waited some more.
My email is hosted on Google Workspace — a corporate email on a custom domain. After a couple of days of retrying, I dug into Google Workspace’s Email Log Search to see what was happening on the receiving end.
Status: Bounced.
The bounce reason:
550 5.7.1 [209.85.220.69] Messages missing a valid Message-ID header are not
550-5.7.1 accepted. For more information, go to
550-5.7.1 https://support.google.com/mail/?p=RfcMessageNonCompliant and review
550 5.7.1 RFC 5322 specifications.Viva.com’s outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008, and was already required by its predecessor RFC 2822 back in 2001.
Google’s mail servers reject the message outright; it never even reaches spam.
The workaround
To unblock myself, I switched to a personal @gmail.com address for the account. Gmail’s receiving infrastructure is apparently more lenient, and the verification email came through.
Having to abandon a business email to sign up for a business payments platform is far from ideal.
The support experience
I reported the issue to Viva.com’s customer support, including the screenshot from Google Workspace’s email logs and a clear explanation of the Message-ID header problem — enough detail for any engineer to reproduce and fix it.
They responded within a few hours:
“We can see your account now has a verified email address, so there doesn’t appear to be an issue.”
No acknowledgment of the technical problem, no escalation to engineering, just a confirmation that I had worked around their bug.
Why this matters
Message-ID is one of the most basic required headers in email. Every email library, framework, and transactional email service generates it by default. Omitting it requires a serious misconfiguration.
For a company that processes payments across Europe, this raises a question: if they can’t get email headers right, what does the rest of the stack look like?
As someone building a business in Greece, I need a reliable payments processor. Viva.com is one of the few that natively supports the Greek instant‑payment system. Stripe, which I would otherwise use, doesn’t support it yet. So I’m forced to depend on infrastructure that can’t pass basic RFC compliance checks.
The broader pattern
This experience fits a pattern I keep encountering with European business‑facing APIs and services: something is always a little bit broken. Documentation is incomplete or hidden in PDFs, edge cases are unhandled, error messages are misleading, and support teams often lack the technical depth to understand the issue.
I don’t think this is a matter of capability; it’s a prioritization problem. When a provider is one of the only options in a market, competitive pressure to polish the developer experience is low. Stripe raised the bar globally, but in markets it doesn’t fully serve, the bar remains low.
The fix
For Viva.com’s engineering team, in case this reaches you: add a Message-ID header to your outgoing transactional emails. It should look something like:
Message-ID: Most email libraries generate this automatically. If yours doesn’t, it’s a one‑line fix. Your Google Workspace users (and I suspect many others) will thank you.