The Hidden Workflow Behind WhatsApp E-Receipt Delivery
A behind-the-scenes look at how payments seamlessly turn into instant WhatsApp E-Receipts.
From APIs to queues and storage, discover the workflow that makes it reliable.
Founder & CTO
- 4 mins read
- 12 Feb, 2020
Every time a payment goes through, customers expect closure. Not later. Not via email they might never open. They expect something immediate. A confirmation. Proof that the transaction is done. Today, that proof often arrives as a WhatsApp message with an attached E-Receipt. From the customer’s side, it feels almost magical. Pay, wait a second, and there it is—ready to download or forward. Behind that simplicity, though, there’s a long chain of steps quietly doing their job.
It Starts With a Simple Request
The journey usually begins with a client system. It could be a POS machine, a billing platform, or a partner application. Once a payment is completed, it calls a Receipt Generation API. The request is straightforward. It carries transaction details, the customer’s mobile number, and a bit of metadata about how the receipt should be sent.
At this point, nothing fancy happens. The API validates the request, stores the transaction data, and generates a callback URL. That callback URL is returned immediately. From the client’s perspective, the job is done. They don’t wait. They don’t block their flow. They just hold on to that callback URL for later. Internally, however, the real work has only just begun.
Why Everything Happens in the Background
If you attempted to use this system in live code trying to generate a PDF and send some WhatsApp with that inside of it, it would survive real traffic. Under the load, responses would grow sluggish and time-outs would spiral out of control and errors would become unpredictable. So rather than attempting to do it all at once, the request goes into a message queue. This is where RabbitMQ steps in.
After the message is queued, the API may respond immediately. Background workers take over the heavy lifting—one step at a time, at a pace the system can handle. Queues also give the system breathing room. If traffic spikes, requests don’t get lost. They wait their turn. If something fails temporarily, retries are handled without manual intervention.
Turning Transaction Data Into a Real Receipt
When a background worker picks up a message, the next task is generating the E-Receipt itself. A PDF service uses predefined templates and fills them with transaction data. The output is a clean, consistent receipt that matches business and compliance needs.
Once the PDF is created, it’s not sent directly to WhatsApp. That would create unnecessary coupling. Instead, the file is stored securely in Azure Blob Storage. A downloadable URL is generated, the document is versioned, and it’s retained for future access or audits. At this point, the receipt exists independently of how it’s delivered. Even if messaging fails, the document is still safe and accessible.
Handing Off to WhatsApp Without Tying Knots
Now comes the messaging part. The system passes the customer’s mobile number, the PDF’s blob URL, and the message template information to a WhatsApp Connector. This connector is built as a WSO2 application and acts as a buffer between internal systems and WhatsApp’s APIs.
That separation matters more than it sounds. WhatsApp APIs change. Rate limits vary. Vendor behaviour isn’t always predictable. By isolating all of that within a connector, the core platform stays stable even as external systems change. It uses the blob URL to pull out the PDF, attach it to a WhatsApp message and then it sends via WhatsApp Business API. For the customer, this collapses into a single moment: A new message pops up.
Knowing What Happened After the Message Is Sent
Delivery doesn’t end with sending. WhatsApp sends back status updates—queued, sent, delivered, sometimes even read. These updates flow back through the connector and into the core system, where database records are updated accordingly.
When the client application later calls the callback URL it received earlier, it gets a clear answer. Was the receipt sent? Delivered? Did something fail? This gives clients visibility without exposing how many systems were involved in making it happen.
When Things Go Wrong (And How Teams See It)
No system is perfect. Messages fail. Numbers are wrong. Networks glitch. That’s why operational visibility matters. A separate dashboard allows authorized users to view notification logs, check delivery status, resend messages, and download stored receipts. Support teams don’t have to dig through logs or databases. Compliance teams can retrieve documents when needed.
Why This Setup Holds Up in the Real World
What makes this flow work isn’t one tool or one service. It’s how responsibilities are split.
- APIs stay fast because they don’t block.
- Queues absorb load and smooth out spikes.
- Storage keeps documents safe and accessible.
- Connectors protect core systems from third-party chaos.
- Callbacks give clients clarity without complexity.
Each piece does one thing, and that’s what keeps the whole pipeline reliable.
The Quiet Work Behind Instant Confirmation
From the outside, sending an E-Receipt on WhatsApp looks simple. In reality, it’s a carefully timed handoff between systems that need to be fast, fault-tolerant, and observable. Customers don’t need to know any of this—and that’s exactly the point.
At 10decoders, this is how we think about backend systems: hide the complexity, respect real-world constraints, and make sure that when something matters to the user, it arrives instantly and works every time. That quiet reliability is what turns a transaction into trust.
